matthew, i'm going to be bluntly honest here. it sounds like a complete nightmare.
i see nothing here that a userspace implementation plus an appropriate selinux policy couldn't gain you. if a credential / ACL "cache" is provided in a userspace daemon, which provides oh, say, a unix domain socket interface, and you created an selinux policy which protected access to those sockets, not only are you done, but also if you port your credential cacheing userspace daemon to other unixen that don't happen to have selinux, so what? at least it's portable: you don't _have_ to "layer" selinux on top. there are tricks that can be played when providing a unix domain socket interface, to ensure that only a specific uid has access to an interface, in a way that the daemon can be absolutely sure that only that uid has access (except root of course). you connect to a 0777 accessible socket, you say "this is my uid", then the daemon creates a temporary directory, chmods it 0700, chowns it to that uid, creates a unix-d-sock in that directory, 0600 chmods and chowns it, and then sends the location of that directory down the 0777 socket. (the creation of the directory is necessary because some unixen cannot handle chmod on a socket!) the client disconnects from the 0777 socket and then reconnects to the temporary socket. the daemon therefore knows that only a process with that uid is able to access that socket. you could even, on linux, play tricks with /proc (similar to what lsof does) to ensure that only a particular _process_ has access to a socket. ... but i believe this [restricting processes] would be much better / cleanly achieved using an selinux policy, setting up selinux domains to restrict access. l. On Wed, Jan 26, 2005 at 01:41:09PM -0800, Matthew N. Andrews wrote: > > such that a userspace credential cache would be insufficient? > > > > in other words, if i log in as user1 and create boat-loads > > of processes, is there _any_ circumstance under which any > > arbitrary user2 _needs_ access to the cached credentials > > of user1? > > > I think you're missing a key feature of pags here. you can have a > process acquire credentials that: > > 1) other processes with the same uid/gid cannot access. > 2) are accessible to child processes with a differend uid/gid, unless > specific actions are taken to drop access by an intermediat > descendant/ancestor. > > and yes, there are circumstances when changing effective uid needs NOT > to drop access to my credentials. in particular, setuid programs run by > me should retain access to my afs credentials. > > -Matt Andrews > > > l. > > > >-- > ><a href="http://lkcl.net";>http://lkcl.net</a> > >-- > >_______________________________________________ > >OpenAFS-devel mailing list > >[email protected] > >https://lists.openafs.org/mailman/listinfo/openafs-devel > > > > > -- -- <a href="http://lkcl.net";>http://lkcl.net</a> -- _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
