Re: [9fans] infauth factotum bug?

Re: [9fans] infauth factotum bug?

[Nathaniel W Filardo]

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

On Tue, May 06, 2008 at 01:10:12PM +0100, rog@vitanuova.com wrote:
> i haven't used the inferno 9auth stuff to log in as more
> than one user, hence i guess i wouldn't have tickled that bug.
> 
> what does 'cat /mnt/factotum/ctl' report after adding the key for user=nwf?

I'm really confused now; I'm going to forward this to 9fans in hopes that
somebody can explain.  [For those of you now joining the conversation, the
original, off-list thread was started because Inferno's factotum and infauth
wouldn't let me play the first dance here; the second 9cpu, with -k
'user=bootes' still logged me in as nwf without prompting for a key.]

On my Plan 9 terminal, if I run

term% echo delkey > /mnt/factotum/ctl
term% cpu -h sea.cs.jhu.edu -k 'user=nwf'
[add key dance]
cpu% exit
term% cpu -h sea.cs.jhu.edu -k 'user=bootes'
[add key dance]
sea# exit
term% cat /mnt/factotum/ctl
key proto=p9sk1 dom=acm.jhu.edu user=nwf password!
key proto=p9sk1 dom=acm.jhu.edu user=bootes password!

This is as I expect.  But if I reverse the order of the cpu commands, I
don't get asked for nwf@'s password.  If I then try to log in as another
real user on the system, I get asked for that user's password.

term% echo delkey > /mnt/factotum/ctl
term% cpu -h sea.cs.jhu.edu -k 'user=bootes'
[add key dance]
sea#
term% cpu -h sea.cs.jhu.edu -k 'user=nwf'
[no key dance is necessary]
cpu%
term% cpu -h sea.cs.jhu.edu -k 'user=me'
!Adding key: dom=acm.jhu.edu proto=p9sk1 user=me
[I don't know me@'s password, so I abort by pressing Del.]
cpu: can't authenticate: sea.cs.jhu.edu: auth_proxy rpc write:
p9sk1@acm.jhu.edu: '/factotum' file does not exist.
term% cat /mnt/factotum/ctl
key proto=p9sk1 dom=acm.jhu.edu user=bootes password!

sea's /lib/ndb/auth contains the usual speaksfor relationship:
  hostid=bootes uid=!sys uid=!adm uid=*

sea's /lib/keys.who contains:
  bootes|bootes host owner|bootes|JHUACM|officers@acm.jhu.edu|officers@acm.jhu.edu
  nwf|nwf|Nathaniel Wesley Filardo|JHUACM|nwf@acm.jhu.edu|officers@acm.jhu.edu
  me||Venkatesh Srinivas|JHUACM|me@acm.jhu.edu|officers@acm.jhu.edu

sea's /lib/users contains:
  adm:adm:adm:sys,bootes
  glenda:glenda:glenda:
  bootes:bootes::
  me:me::
  nwf:nwf::
  sys:sys::glenda,me,nwf,bootes

My username on my terminal is nwf.

The question is: why don't I have to present a password to log in as nwf@
after I have logged in as bootes?  Why doesn't this explanation hold for
me@?

Thanks much.
--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 192 bytes --]

Re: [9fans] infauth factotum bug?

[roger peppe]

On Tue, May 6, 2008 at 9:38 PM, Nathaniel W Filardo <nwf@cs.jhu.edu> wrote:
>  term% cpu -h sea.cs.jhu.edu -k 'user=nwf'

i think the answer may be to do with the fact
that you're using "-k 'user=foo'" rather than "-u foo".
i haven't got time to look into it
properly right now, but it's worth trying.

  rog.

Re: [9fans] infauth factotum bug?

[Nathaniel W Filardo]

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

On Wed, May 07, 2008 at 11:00:13AM +0100, roger peppe wrote:
> On Tue, May 6, 2008 at 9:38 PM, Nathaniel W Filardo <nwf@cs.jhu.edu> wrote:
> >  term% cpu -h sea.cs.jhu.edu -k 'user=nwf'
> 
> i think the answer may be to do with the fact
> that you're using "-k 'user=foo'" rather than "-u foo".
> i haven't got time to look into it
> properly right now, but it's worth trying.
> 
>   rog.

No change: nwf@ then bootes@ asks for two passwords, but still can log in as
nwf@ without a password after logging in as bootes@ and can't log in as me@
without one.  Indeed, this is expected as a cursory inspection of
/sys/src/cmd/cpu.c suggests that the only authentication changes made by -u
are as if the user had typed -k 'user=...' intead (there are some small
changes made in the file system code it seems to make uid and gid match the
argument of -u which doesn't happen with -k, but these ought not impact
authentication).

Thanks much.
--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 192 bytes --]

Re: [9fans] infauth factotum bug?

[Russ Cox]

> term% echo delkey > /mnt/factotum/ctl
> term% cpu -h sea.cs.jhu.edu -k 'user=bootes'
> [add key dance]
> sea#
> term% cpu -h sea.cs.jhu.edu -k 'user=nwf'
> [no key dance is necessary]
> cpu%
> term% cpu -h sea.cs.jhu.edu -k 'user=me'
> !Adding key: dom=acm.jhu.edu proto=p9sk1 user=me
> [I don't know me@'s password, so I abort by pressing Del.]

> My username on my terminal is nwf.

> The question is: why don't I have to present a password
> to log in as nwf@ after I have logged in as bootes?

Because bootes is the remote host owner.
If factotum knows that key, it will use it to
vouch for you.  This is why you can still mount
things from a cpu server that you connected
to using ssh or cron or rx or any other
non-factotum-supplying method.

> Why doesn't this explanation hold for me@?

Your user name on the terminal is nwf.
Factotum will vouch for you, not lie for you.


All that said, the first cpu should not be adding
the bootes key for use in the speakfor role:
it should be adding it with role=client only,
and then factotum won't use it to authenticate
as nwf.  I thought it already did that.  Please
send the output of cat /mnt/factotum/ctl after
the above sequence.  Thanks.

Russ

Re: [9fans] infauth factotum bug?

[Nathaniel W Filardo]

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

On Thu, May 08, 2008 at 10:02:18AM -0400, Russ Cox wrote:
> > term% echo delkey > /mnt/factotum/ctl
> > term% cpu -h sea.cs.jhu.edu -k 'user=bootes'
> > [add key dance]
> > sea#
> > term% cpu -h sea.cs.jhu.edu -k 'user=nwf'
> > [no key dance is necessary]
> > cpu%
> > term% cpu -h sea.cs.jhu.edu -k 'user=me'
> > !Adding key: dom=acm.jhu.edu proto=p9sk1 user=me
> > [I don't know me@'s password, so I abort by pressing Del.]
> 
> > My username on my terminal is nwf.
> 
> > The question is: why don't I have to present a password 
> > to log in as nwf@ after I have logged in as bootes?  
> 
> Because bootes is the remote host owner.
> If factotum knows that key, it will use it to
> vouch for you.  This is why you can still mount
> things from a cpu server that you connected
> to using ssh or cron or rx or any other 
> non-factotum-supplying method.

OK, so how does my factotum know that bootes is the remote host owner, or
does it just try to authenticate with that key despite that it doesn't match
the keyspec user=nwf and see what happens?

> > Why doesn't this explanation hold for me@?
> 
> Your user name on the terminal is nwf.
> Factotum will vouch for you, not lie for you.

OK.  This is, to me, counterintuitive behavior; if I have sufficient
credentials it's not really "lying".  It seems bizarre that factotum would
volunteer my terminal's user id, which is totally disjoint from the
user id namespace of the cpu server.

> All that said, the first cpu should not be adding
> the bootes key for use in the speakfor role:
> it should be adding it with role=client only,
> and then factotum won't use it to authenticate
> as nwf.  I thought it already did that.  Please
> send the output of cat /mnt/factotum/ctl after
> the above sequence.  Thanks.

I may be out of date, let me replica/pull and get back to you.

> Russ

Thanks for your answers.
--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 192 bytes --]

Re: [9fans] infauth factotum bug?

[erik quanstrom]

> It seems bizarre that factotum would
> volunteer my terminal's user id, which is totally disjoint from the
> user id namespace of the cpu server.

if the "user id namespace" is disjoint, does that mean you are running
more than one auth server?

- erik

Re: [9fans] infauth factotum bug?

[Russ Cox]

> OK, so how does my factotum know that bootes is the remote host owner, or
> does it just try to authenticate with that key despite that it doesn't match
> the keyspec user=nwf and see what happens?

The first step in the authentication protocol is to
exchange information about who is on what side,
and the remote side says it is bootes in the domain
acm.jhu.edu.  Factotum doesn't just try the key blindly;
it knows the key is valid.

>> > Why doesn't this explanation hold for me@?
>>
>> Your user name on the terminal is nwf.
>> Factotum will vouch for you, not lie for you.
>
> OK.  This is, to me, counterintuitive behavior; if I have sufficient
> credentials it's not really "lying".  It seems bizarre that factotum would
> volunteer my terminal's user id, which is totally disjoint from the
> user id namespace of the cpu server.

The remote factotum has a bootes key valid for the
server role, and the local factotum has a bootes key
valid for the speakfor role.  You're only supposed to
do that when the two machines are in the same authentication
domain and share their user id name space.
(That's the whole reason speakfor exists.)
If you don't want factotum to speak for you, you shouldn't
give it bootes's key in the speakfor role.

The real problem here is that cpu -k 'user=bootes'
has managed to request the key for all roles, not just
for the client role.  That's the part I don't understand.
When it says !adding key, the line describing the key
should say "role=client", and if the key is added with
that tag, then you shouldn't see the behavior above.
That's why I want to see your /mnt/factotum/ctl file.

Russ