Re: [9fans] infauth factotum bug?

["Russ Cox" <rsc@swtch.com>]

> 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