On Wednesday, July 14, 2004 13:01:18 +0200 Tomas Olsson <[EMAIL PROTECTED]> wrote:
Frank Bagehorn <[EMAIL PROTECTED]> writes:
> if you don't have an allocated PAG ([EMAIL PROTECTED] 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 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
