Kyle Moffett wrote:
Ok, so the requirements are: 1) Shared between multiple processes with sane inheritance 2) Store a pointer to arbitrary arch-independent data structures 3) A unique globally-useable ID to locate a particular combination of credentials, connection data, caches, etc.
Let's flesh out #1 a bit: sane inheritance. That needs to include repudiation. Specifically, a process needs to be able to do two things: 1) to drop its token and ensure that newly acquired tokens are accessible only to its descendant processes, and 2) ensure that its descendants can't "rejoin the old PAG, still in progress" so to speak.
In a previous message, you said:
What about the inheritance rules described above does not work for you? The only way to change the session keyring is with PR_JOIN_SESSION_KEYRING. With that, you can request a new anonymous keyring or join an already created one, assuming you have sufficient permissions.
What exactly constitutes "sufficient permissions" to join an already created keyring? That certainly seems like a very flexible design, but I'm not convinced it meets the "sane inheritance" criterion. PAGs don't let you do that (without doing some evil rootly things anyway). Maybe this keyring thing does let you do everything PAGs can do, but can they keep you from doing everything that PAGs keep you from doing?
As I see it, the keyring system can very simply be dropped in place of the existing setgroups hooks.
I know I'm whistling in the wind here, given that local UNIX groups are so thoroughly ingrained, simple, and efficiently implemented that fundamental changes in that area are extremely unlikely, but each local group membership is exactly equivalent to holding a "local token" for local (and some shared) file systems. They ought to be treated the same way -- and with the same code in the kernel -- as tokens for remote file systems. I'd like to see an implementation that not only could be "dropped in place of the existing setgroups hooks", but could replace all the group stuff at once (and improve it at the same time, which is a tall order given that it's almost trivial now). Not gonna hold my breath on that one, though.
--
+--------------------------------------------------------------+
/ [EMAIL PROTECTED] 919-962-5273 http://www.unc.edu/~utoddl /
/ Marriage is the mourning after the knot before. /
+--------------------------------------------------------------+
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
