Re: [9fans] some thoughts about auth*

[Richard Miller <miller@hamnavoe.demon.co.uk>]

"Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>said:
> 2. I'm not exactly sure that I understand why Nvrsafe has
>    this .authkey member in it. The only place where it is
>    being used by the regular Plan9, not a dedicated Plan9
>    FS is in cmd/disk/kfs/auth.c which doesn't seem to make
>    much sense, when nobody sets it up.

and presotto@plan9.bell-labs.com replied:
> There used to be a key for connecting to other resources and
> one for letting people log onto the console so that they could
> use it (for cpu and file servers).  The latter was the authkey
> and we eventually gave up on the function altogether.  The naming
> is hokey, I'm to blame.

However, I'm to blame for using authkey as the place to stash the
authentication key in kfs.  In the 3rd edition kfs it was
read in from #c/key.  In 4th edition there's no #c/key, so the
whole Nvrsafe structure is read from nvram (or simulated nvram on
a disk partition or floppy), and therefore kfs should now be
using machkey.  (authkey will be empty unless your nvram is left
over from a 3rd edition ugrade.)

While looking into this, I found another error in the 3e->4e
transition of the kfs network support.  If you want 3e clients
to be able to mount a kfs exported by a 4e cpu server, the following
changes appear to be necessary:

/sys/src/cmd/disk/kfs/9p1.c:72 d ./9p1.c:71
< 	memmove(ou->chal, cp->chal, sizeof(ou->chal));
/sys/src/cmd/disk/kfs/9p1.c:73 a ./9p1.c:73
> 		memset(ou->chal, 0, sizeof(ou->chal));
/sys/src/cmd/disk/kfs/9p1.c:76 a ./9p1.c:77
> 		memmove(ou->chal, cp->chal, sizeof(ou->chal));

/sys/src/cmd/disk/kfs/auth.c:61 c ./auth.c:61
< 	convM2T(in->ticket, &t, nvr.authkey);
---
> 	convM2T(in->ticket, &t, nvr.machkey);