On Thursday, March 30, 2006 07:41:05 PM -0600 Nicolas Williams <[EMAIL PROTECTED]> wrote:
> 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. Yes, it does. PAG's are not sets of credentials; they are a form of process group. Subsystems like NFS and AFS need to do things like keep track of which established connections are authenticated with whose credentials, and which cached access rights apply to which sets of credentials. The latter is much more important than it may seem at first glance. For a shared cache on a multi-user (multi-credential) system to be effective, the cache manager must know when it is allowed to use cached data to satisfy a request. >> 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. It's not PAM, kinit, or keylogin that I'm worried about. Creating completely new PAG's and new app data types to existing PAG's are both easy. The hard part arrives when you want to create a new PAG which shares some application data with its parent. And it's not just the splitting that's hard, but presenting the result to the user. > 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. Correct. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
