[OpenAFS-devel] Re: openafs / opendfs collaboration

[Kyle Moffett]

On Jan 25, 2005, at 12:41, Jeffrey Hutzelman wrote:
> 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.

My main point is, why do we need PAGs?  You don't just have to store
credentials in a keyring, you can store a (single) shared connection.
Basically any in-kernel or out-of-kernel security-related BLOB that
needs to be associated with a process can be used through the keyring
system. Ex:

kinit:
	Connect to Kerberos server, authenticate, get keys, put them in
	the session keyring
aklog:
	Get the TGT from any keyring where it's available, connect to
	the Kerberos server, get an AFS service ticket, put that in the
	same keyring as the TGT.  Then "create" an AFS connection "key",
	passing in a specially formatted BLOB consisting of the service
	ticket, connection parameters, and other settings.  The AFS
	kernel module would decode the BLOB, create the connection, and
	link the connection through the newly generated "key".
file ops:
	Get the first AFS connection "key" found, and use it to perform
	file operations.

The session key is _NOT_ a UNIX session, but a key shared across all
processes descended via fork/vfork/clone/exec from the process where
the keyring is originally set.  This means that you would just have
the PAM module create a new key-session and put the keys in there.

>    In addition, the filesystem may cache other data associated with a
>    particular authentication context.  For example, when we fetch a 
> file
>    from the fileserver, it gives us information about what access is
>    available on that file to the user doing the fetch.  We cache that
>    information, so we don't have to go back and ask the fileserver to
>    reevaluate the ACL on every operation.  However, those cached rights
>    must be associated with the authentication context in which the
>    original access was done -- otherwise, we might grant some process
>    too much access to a cached file.

This works with the above stuff too, and more elegantly than the old
PAG code did too, because it doesn't need to hack the kernel groups
code.

> (2) In UNIX-speak, "session" has a very specific technical meaning; it 
> is
>    one of several kinds of sets of processes, used for a specific 
> purpose.
>    Unfortunately, the term has been overloaded several times by people
>    looking for a good word to describe a concept they cared about.  So,
>    in addition to UNIX sessions, we have PAM sessions and X11 sessions.

This is a new and distinct "session", I call it here a "key-session".

>    As I understand it, the keyring code supports associating a keyring
>    with a UNIX session.

This is completely false.  Please read linux/Documentation/keys.txt from
a recent kernel.

>> It's very fast, simple, and well designed
>
> Says the guy who designed it. :-)

I didn't design or write it. :-P  I helped out David Howells by
commenting on his code and design, but I did not code a single line for
it.

> Personally, I think it spends too much time on concepts like 
> keys-as-files
> and not enough on getting the inheritance rules right.

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.

> Based on our earlier discussion, I think we'll be able to shoehorn what
> we need into the keyring mechanism.  But it will be ugly, because what
> we need is not a place to store keys, but an identifier to label things
> with.

Just attach your connection and cache data to a key of an "AFS-conn" 
type
registered by the AFS module, and you get all of the same inheritance
functionality as traditional group-based PAGs, except without the hacks
introduced to hook the kernel group-manipulation syscalls.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r  
!y?(-)
------END GEEK CODE BLOCK------