[OpenAFS-devel] Re: openafs / opendfs collaboration

[Luke Kenneth Casson Leighton]

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.