> In other words, PAGs suck.
If you feel strongly this way, could you recommend another method for
providing the required services? There are presumably many ways to do
this; this just happens to be the one we are currently considering. I
would welcome a more general solution to the problem. The problem would
appear to be that there is a need for finer granularity management of keys
than a mere mapping to UID (which is what Coda currently does).
There are times when you want to retain access to files when running a
setuid binary, but not when you su, for example. Also, root might want to
aquire tokens for the running of a particular daemon, but not for general
use at a root shell. Given an incoming syscall, which identity are the
requests associated with? Or, in a more applied sense, given an incoming
syscall, which set of existing RPC2 binds should I use for the request;
should I open a new Bind, is this identity authorized to access a
particular file currently in the Venus cache, etc.
One approach is that processes are in "groups" for the purposes of
distributed file system identities. Usually people aquire an identity for
a session, expect different identities for different sessions, etc.
However, the existing UNIX process groupings have other purposes --
process groups are used for Job control, and sessions are too fine grained
(if I run xterm, which will be associated with a new pty, I want to be in
the same authentication group). And UNIX UID does not seem to be
sufficient. Hence a new grouping, and that grouping is named the PAG,
currently.
The semantics of PAG-manipulation calls is still up in the air. Thus far,
the preferred API has merely been newpag() -- the establishment of a new
pag. Across forks, execs, the PAG is retained. A natural implementation
of this would be to assign unique PAGids, similar to PIDs, assigning them
sequentially until wrap-around, and then just avoiding collisions. If a
process wishes to inherit tokens across a newpag() call, it must retrieve
a copy of the tokens from Venus before the call, then give them back to
Venus afterwards (and Venus will know based on the PAG where to store the
tokens).
There are issues of garbage collection; we are currently leaning towards
Venus walking the process list once in a while and garbage collecting its
old PAGs no longer referred to. This leads to possible attacks by
processes doing a lot of newpag() calls to wrap around, which is something
we need to address. I have leant towards the kernel possible providing
similar structures for storing PAG relationships as it does for process
groups -- i.e., the normal list, hashing by PAGid to find members, etc,
and possibly a call-back to Venus of some kind indicating garbage
collection should occur when the number of members reaches 0.
This has problems if you wish to use multiple distributed file systems
(such as AFS and Coda at the same time) which would presumably use the
same PAGs -- who does the callback go to, etc. There are possible race
conditions, etc.
So we do welcome any other solutions to the problem. The PAG seemed to be
a fairly natural way to do it -- Peter and I hashed out such an idea
ourselves before discovering that DFS/AFS already had such a mechanism as
we needed it. Our semantics are almost identical, I believe, although the
planned implementation is different. If there is a better approach, I
would greatly appreciate hearing about it.
Robert N Watson
Carnegie Mellon University http://www.cmu.edu/
SafePort Network Services http://www.safeport.com/
robert@fledge.watson.org http://www.watson.org/~robert/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu