[OpenAFS-devel] Re: openafs / opendfs collaboration

[Jeffrey Hutzelman]

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.  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) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA