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. 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".
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. 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.
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.
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.
(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.
In the interest of clarity, a few definitions:
- A UNIX session works like a UNIX process group - a process can call
setsid() to create a new session and become a "session leader";
the new session is named for the pid of its leader. When a process
forks, the new process is in the same session as its parnet, unless
and until it calls setsid() to create a new session. UNIX sessions
are used for managing terminals. This is the only kind of session
the Linux kernel knows about. - A PAM session relates to the things that happen when you log in,
and again when you log out. It's not really a set of processes at
all - just an instance of someone being logged in to the machine.
Pretty much only the PAM subsystem knows about this. - An X11 session consists approximately of everything that happens
from when you start the X server (or log in via xdm) until it exits
(or you log out). It contains all the applications you run while
you are logged in. This is the mechanism used to store state about
what applications you are running, where windows are placed, etc,
across login sessions. It is known to the session manager program
and to session-aware X11 applications. - I'll use the term "login session" to describe everything I do from
when I log in to a machine until I log out. This might be the same
as an X11 session, or it might not. It could include suspended
shells, multiple terminals created by screen, etc.As I understand it, the keyring code supports associating a keyring with a UNIX session. Unfortunately, unless a newly-created UNIX session automatically inherits the keyring of the session which previously contained the new session leader, this is not enough. In the course of a single login session, there may be many active UNIX sessions. Every terminal (xterm, screen window, etc) will be a separate UNIX session. If I run aklog in one window, it must be the case that the new tokens take effect for every process which shares the same authentication context -- it would be unacceptable for me to have to run aklog in every window!
It's very fast, simple, and well designed
Says the guy who designed it. :-)
Personally, I think it spends too much time on concepts like keys-as-files and not enough on getting the inheritance rules right. But otherwise, I won't argue -- it's basically the right approach for managing keys and credentials.
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.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
_______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
