[OpenAFS-devel] Re: openafs / opendfs collaboration

[Luke Kenneth Casson Leighton]

On Tue, Jan 25, 2005 at 12:41:25PM -0500, Jeffrey Hutzelman wrote:
> On Monday, January 24, 2005 17:25:38 -0500 Kyle Moffett 
> <mrmacman_g4@mac.com> wrote:
> 
> >The keyring stuff essentially allows you to associate arbitrary BLOBs with
> >processes via a simple kernel interface.  OpenAFS could store the
> >credentials in a session keyring and all processes in that session would
> >have access to the credentials.  Then OpenAFS could just run a key search
> >for the credentials when it needs to perform operations (Such as passing
> >them to the server) with them.
> 
> There still seems to be some confusion here on a couple of key points.
> 
> (1) A PAG is not a set of credentials.  It is a set of _processes_ which
>    share the same authentication context.  

 *whew*.  that's good.

> The distinction may seem minor
>    if you are used to thinking in terms of encrypted local filesystems,
>    but it is actually of critical importance.  A caching distributed
>    filesystem like AFS (or DFS, or NFSv4) maintains open connections to
>    servers on behalf of users.  Every connection is established using a
>    specific set of credentials, and operations done over that connection
>    are subject to the access rights associated with those credentials.
>    The authentication process is an exchange that may potentially take
>    multiple round trips (depending on the technology in use); it's not
>    simply "pass the credentals to the server".

 Windows NT authentication is the same - in an NT3.5->4.0 and NT 5.0
 (aka 2000) in "NT domain backwards-compatibility" mode it's an exchange
 of in excess of 15 round-trips just to perform authentication: if you
 are contacting a domain member server or a PDC with an inter-domain
 trust relationship then it's double that (because the server needs to
 contact your PDC on your behalf).

 this isn't funny to be duplicating, and keeping an open
 connection to the PDC can help short-cut the number of authentication
 packets exchanged drastically, as can credential cacheing.


>    Obviously, it is critical that any operations be done with the right
>    credentials.  And, the cost of creating connections is high enough
>    that it is important to share connections between processes whenever
>    possible - otherwise, you'd be creating a new connection for every
>    ls or whatever.  

 winbindd - written by tim potter - does exactly this.  pam_winbindd
 contacts winbindd, which performs authentication on your behalf.

 so there do exist userspace applications which do the same job as
 keyring.

> Meeting both of these goals means that processes
>    which are in the same authentication context should share connections,
>    while processes in different authentication contexts should not.  To
>    make this happen, we need to keep track of which processes are in the
>    same authentication context.

 this _can_ be managed all in userspace, by writing appropriate APIs
 that are protected behind appropriate access privileges on, say unix
 domain sockets.

 i'd be interested to hear a justification as to why it is _necessary_
 for this to be done in kernel.

>    Both of these are ways in which we essentially need an identifier for
>    sets of processes in the same authentication context, so we can label
>    other data we track.  We don't need a place to store credentials; we
>    need a way to associate processes.
 
 why does that require specific assistance from the kernel?

 is there any overlap between different user contexts,
 such that a userspace credential cache would be insufficient?

 in other words, if i log in as user1 and create boat-loads
 of processes, is there _any_ circumstance under which any
 arbitrary user2 _needs_ access to the cached credentials
 of user1?

 l.
 
--
<a href="http://lkcl.net">http://lkcl.net</a>
--