[OpenAFS-devel] [LKML] Re: In-kernel Authentication Tokens (PAGs)

[Jeffrey Hutzelman]

On Wednesday, July 14, 2004 13:01:18 +0200 Tomas Olsson 
<tol@stacken.kth.se> wrote:

> Frank Bagehorn <FBA@zurich.ibm.com> writes:
>
>> > if you don't have an allocated PAG (PAG@localhost session key?), your
>> > uid is used as the key under which to store your tokens. This is handy
>> > as you don't need to initialize tokens for every login if you do
>> > several.
>>
>> And it becomes a problem in a case where e.g. several admins log into the
>> root account.  You do want them to have separate PAGs with their
>> credential. You don't want to get another admins AFS token just because
>> he logged in...
>>
> True. Shared logins are tricky, and ticket forwarding changes a lot of
> things. One could argue that a daemon that receives forwarded tickets
> should give you a new PAG. Should this be up to the daemon or be an OS
> decision?

"should" is irrelevant here.
The OS cannot tell when such an event happens.
It doesn't know what a "daemon" is, let alone a "daemon that receives 
forwarded tickets", and wouldn't know the right time to do this.

It's clear from AFS experience that calls to setuid or setgroups are not 
the right place to automatically change PAG's.

> The question is in which cases a default PAG is desirable or undesirable,
> or where the possibility to join a PAG in some way could be a solution.

So, my understanding is that Kyle's design allows for a keyring to be 
associated with a UID.  That is effectively the same as a default PAG, 
except without the "jail" effect.

Personally, I don't consider the inability to go back to the default UID 
pag to be a deliberate feature; it's just a side-effect of the way we 
implement PAG's (by making it so that setgroups always preserves a PAG) 
combined with the lack of any sort of switch-to-this-PAG operation.


-- Jeff