Messages in this thread | | | Date | Sat, 21 Feb 1998 11:45:32 -0500 (EST) | From | Robert Watson <> | Subject | Re: PROPOSAL: Process Authentication Groups (PAGs) (fwd) |
| |
On Fri, 20 Feb 1998, Peter J. Braam wrote:
> 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
| |