From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5997b562ef90863c347d5fa609d088da@hamnavoe.demon.co.uk> To: 9fans@cse.psu.edu Subject: Re: [9fans] some thoughts about auth* From: Richard Miller MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Thu, 7 Nov 2002 19:47:36 +0000 Topicbox-Message-UUID: 186e0b4a-eacb-11e9-9e20-41e7f4b1d025 "Roman V. Shaposhnick" 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);