[OpenAFS-devel] Re: openafs / opendfs collaboration

[Todd M. Lewis]

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.
-- 
    +--------------------------------------------------------------+
   / Todd_Lewis@unc.edu  919-962-5273  http://www.unc.edu/~utoddl /
  /        Marriage is the mourning after the knot before.       /
+--------------------------------------------------------------+