Re: [9fans] some thoughts about auth*

Re: [9fans] some thoughts about auth*

[Richard Miller]

"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);

Re: [9fans] some thoughts about auth*

[Roman V. Shaposhnick]

On Thu, Nov 07, 2002 at 07:47:36PM +0000, Richard Miller wrote:
> "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>said:
> 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);


That's exactly what I had in mind but was afraid to suggest :). Well,
with these changes in mind now there is absolutely no place in
Plan9 sources ( modulo stand alone fs ) where nvr.authkey can be found.
Of course I understand that asking for ditching nvr.authkey from Nvrsafe is
too much to ask, but it might be reasonable to mark it as deprecated in
a header file. That way, people will be much less likely to be confused
in the future.

How about that ?

Thanks,
Roman.

P.S. Is second declaration of the nvr in the disk/kfs/auth.c at line
35 really necessary ? Or is it just copy'n'paste artifact ?

Re: [9fans] some thoughts about auth*

[Roman V. Shaposhnick]

On Fri, Nov 08, 2002 at 08:13:57AM -0500, presotto@plan9.bell-labs.com wrote:
> Since they have the same contents, perhaps we can change both
> fs's to look in the same place?

  That'll be splendid! And not too hard ( judging from greping through
  source tree ).

Thanks,
Roman.

P.S. With .authkey gone, there is even no much need to change the name
'getauthkey'.

Re: [9fans] some thoughts about auth*

[presotto]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

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.

[-- Attachment #2: Type: message/rfc822, Size: 2112 bytes --]

From: "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>
To: 9fans@cse.psu.edu
Subject: [9fans] some thoughts about auth*
Date: Thu, 7 Nov 2002 03:25:33 +0300
Message-ID: <20021107032533.A30255@unicorn.math.spbu.ru>

1. Isn't it strange that getauthkey.c:getauthkey actually
   returns .machkey ? Is there any historical reason for
   it to be getauthkey() especially when there is a
   field in Nvrsafe called .authkey ?

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.

   As a matter of fact, I was able to spot it, only because
   in my particular case auth/wrkey *always* sets it to
   'roman' which is honorable, but very weird :)

All in all, I'd be grateful for any insights or explanations.

Thanks in advance,
Roman.

[9fans] some thoughts about auth*

[Roman V. Shaposhnick]

1. Isn't it strange that getauthkey.c:getauthkey actually
   returns .machkey ? Is there any historical reason for
   it to be getauthkey() especially when there is a
   field in Nvrsafe called .authkey ?

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.

   As a matter of fact, I was able to spot it, only because
   in my particular case auth/wrkey *always* sets it to
   'roman' which is honorable, but very weird :)

All in all, I'd be grateful for any insights or explanations.

Thanks in advance,
Roman.