On Thu, Mar 30, 2006 at 08:02:14PM -0500, Jeffrey Hutzelman wrote: > On Thursday, March 30, 2006 06:08:10 PM -0600 Nicolas Williams > <[EMAIL PROTECTED]> wrote: > >Huh? Why should UIDs not conflict with PAGs? What am I missing? > > Because AFS identifies credentials, cached connections, and cached access > rights by a 32-bit number which is either a UID or a PAG. So the > namespaces for those need to not overlap. AFS uses 0x41000000.. 0x14FFFFFF > for PAG's, leaving the rest of the 32-bit space for UID's.
Ugh. > >>> We need a first-class PAG-like thing. > >> > >>Please! Be the first OS vendor on your block to provide them! > > > >Unfortunately it's a bit harder than that. > > > >I have lots of uses for PAGs besides tracking krb5 tix. I don't want a > >PAG-like item per-such use. I want a daemon (least priv and all that) > >that tracks PAG<->{whatever} associations. It has to be lightweight and > >not easily DoSed. And this needs an API. And it needs to allow you to > >create a new PAG while keeping all your old associations and breaking > >only the ones you want to break, which also means some access control > >(euid will do). > > The last is very tricky. To get it right, code has to not actually track a > process's credentials (and associated cached stuff) directly by its PAG, > but by a per-application identifier with a many-to-one mapping between > PAG's and application identifiers. Any application has to be able to add a > mapping from an existing PAG to one of its identifiers, if one doesn't > already exist. And, applications need to be able to ask the question "is > this still in use?". And the fun part - these things have to be possible > not only from user mode but also from the kernel. No, the kernel doesn't need PAGs for itself -- it upcalls to daemons that do (e.g., gssd(1M)) and which can use door_ucred(3DOOR) and friends to find out what the caller's PAG is. > In any event, the API is easy. The hard part is the _user_ interface... The user interface is easy: PAM (not quite in its present form) can handle all logon-time issues, while programs like kinit and keylogin can take care per-application associations in specific cases, and a generic command can list/break any/all associations. Yes, an event facility is needed to detroy credentials on refcount drop to zero. > > >>> The audit session ID comes close to being that, but falls short (for > >>> one, it's 32 bits, so too small, but also audit isn't on by default, > >>> and the model is that you don't change a process' audit session ID > >>> ever once set). Process contracts also come close but fall short in > >>> that a process can be in only one process contract and SMF use of > >>> process contracts would conflict with AFS/DCE-style use of PAGs. We > >>> could build PAGs as extensions to process contracts, or as yet another > >>> process grouping mechanism (which is how PAGs look in AFS). > >> > >>Right; AFS PAG's are just another kind of process group. They happen to > >>have exactly the same inheritance semantics as supplemental groups, > >>except that setgroups() doesn't touch them, and any process can ask for > >>a new one. (In addition, AFS let's you get a new PAG and ask for your > >>parent to be moved into it with you; this lets 'newpag' be a program > >>users can call from the shell. But this behavior is considered an evil > >>aberration that we wish would go away). > > > >In Solaris the way you'd do the "change parent's PAG" is through /proc > >(we really need a stable, public version of the libproc API, which makes > >/proc reall easy to use...). > > > >In fact, you can do the AFS hack today using /proc... > > Not without privileges you can't. Er, well, yes, but that is true even for the case where the process is creating a new PAG with this hack -- this isn't /proc's fault but the result of using supplementary groups to emulate first class PAGs. Nico -- ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos