> On 20 Feb 1998, Aaron M. Ucko wrote:
>
> > Absolutely. However, it's not clear PAGs a la AFS are the right
> > solution. IMO, token sets (TS's for short, pending a better name)
> > should have the following properties:
>
> The purpose of a PAG is NOT to do token management, but to provide
> identity to token managers.
Given the requirements of Coda/AFS/other file systems, PAG does suffice.
It covers correctly, thus far, all cases for either PAG inheritence (or
lack thereof) that have been described to me. However, the PAG is not a
general solution to the problem of UIDs in UNIX. It is unlikely, however,
that the Coda project will be able to address the short-comings of the
UNIX authentication/authorization model. These are certainly issues that
need to be addressed, but not in this forum. Possible solutions to the
problem do include Token-managing support in the kernel. The
implementation of "superior UNIX auth*" is a very long-term project -- I
would imagine it being on the order of years.
But the Coda authentication issue is a problem that needs to be solved in
months -- it is important that, given the state of Coda, we know what the
general solution available to us is, and that we can integrate it into the
code. I recommend that PAG be designed such that supersets of PAG
functionality can be very broad, but that PAG meet our specific
requirements very closely.
I am very interested in working on a better long-term solution that
address many, if not all of current-day problems in UNIX -- such as the
binding of <1024 ports by root, management of authentication by groups of
processes, the ability of processes to hold multiple identities and
interact with multiple distributed file systems, user keying of IPsec,
coming up with a better solution than ssh-agent for identity management,
etc. But not here. I will shortly be creating a mailing list for the
discussion of such design in the context of FreeBSD/BSD-style kernels. I
welcome you to join this list once it is created so you can see some of
the ideas we have been bouncing around.
> > (a) Have a variable mapping from sessions or process groups to
> > TS's; this requires either the kernel or the cache manager to
> > keep track of more state, and has the disadvantage (shared
> > with AFS PAGs) that there's no way to start processes which
> > should have different TS's from the same shell.
The proposed clog -e behavior allows you to aquire tokens and a new PAG
for a specific child, such as a daemon. The key to use with clog can be
provided via stdin, or (shortly) from a file similar to srvtab. Thus root
could start different daemons with different tokens, yet all with the root
UID (so that they could bind, etc).
> In due course there will be many different types of tokens. I think that
> the extra layer of abstraction formed by the PAG will allow easy token
> management for a while to come.
I have a few qualms, but strongly feel that the PAG semantics are
sufficient to last us a number of years. We can implement PAG today, and
Coda needs PAG today. A better answer is a good goal, but is not
something we can achieve in the required timespan. PAGid behavior fits
into the general design of process grouping behavior of UNIX quite well --
it is minimalist (a good thing) and is sufficient for our ends. These
seem like good arguements for going ahead with this plan, and then
spending a few years designing a new system for UNIX to authorize over.
> If you centralize things in the kernel, you would have different problems:
> how would you use one token for AFS and another for Coda etc.
I am still concerned about race conditions and garbage collection. We
need to work out a reliable way for all interested parties to discover
that a PAG is no longer in use. As I have pointed out in a private email,
walking /proc is not sufficient, as given PAGid wraparound, race
conditions abound. Venus-side access to PAG data is probably what we
should be talking about next. When Venus receives a syscall via /dev/cfs,
it will presumably include the PAGid; that is fairly straight-forward. If
it has not seen the PAG before, and the request provides tokens, it
creates local state. Now as requests come in with the PAG, it can use
that local state (tokens, set of RPC2 Binds, etc) to retrieve data,
authorize actions, etc. The question is, how do we know when to
garbage-collect the state.
We can do that whenever no processes remain in the PAG -- i.e., when
either a) the last process in the PAG dies, or b) when the last process
in the PAG calls newpag(). We need to determine when this happens
reliably, without possibility of context-switch during this determination
(so reads to /proc are out! :). It seems that this is a service the
kernel must provide. Not only that, but Venus must process these
notifications immediatly without providing *any* services before then, as
they might be associated with the PAGid that is being expired. These
incoming requests might have that PAGid in the event that a wrap-around
race condition were employed. So all other behavior must be blocked until
the PAG issues are dealt with.
Is this correct? Is there a better approach?
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