On Tue, Jan 25, 2005 at 05:28:42PM -0500, Kyle Moffett wrote: > On Jan 25, 2005, at 07:53, Todd M. Lewis wrote: > >Kyle Moffett wrote: > >>The keyring stuff essentially allows you to associate arbitrary BLOBs > >>with processes via a simple kernel interface. OpenAFS could store > >>the credentials in a session keyring and all processes in that > >>session would have access to the credentials. Then OpenAFS could > >>just run a key search for the credentials when it needs to perform > >>operations (Such as passing them to the server) with them. It's very > >>fast, simple, and well designed > > > >This is encouraging. How closely do the semantics of "session keyring > >and all processes in that session" match those of PAGs? (Group > >membership inheritance across fork/exec seems pretty clear; sessions > >have always seemed a little fuzzy to me.) > > I describe in more detail in my other email, but basically a given > "key-session" is preserved across clone/fork/vfork/exec. The only > way to change "key-session"s is with the keyctl syscall, using > PR_JOIN_SESSION_KEYRING to join an existing keyring or create a new > anonymous one. what happens when a process performs a setuid / seteuid call?
i.e. what happens to a file server (such as smbd) which is dropping in-and-out of root to perform file operations (using seteuid), but that file server has to perform authentication to an external [networked] service, and uses a "keyring" as a credential cache? also relevant: if setuid / seteuid is taken into account, is an selinux security context _also_ taken into account? l. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
