[lkml]   [1998]   [Feb]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PROPOSAL: Process Authentication Groups (PAGs) (fwd)
    On 20 Feb 1998, Aaron M. Ucko wrote:

    > In other words, PAGs suck.

    If you feel strongly this way, could you recommend another method for
    providing the required services? There are presumably many ways to do
    this; this just happens to be the one we are currently considering. I
    would welcome a more general solution to the problem. The problem would
    appear to be that there is a need for finer granularity management of keys
    than a mere mapping to UID (which is what Coda currently does).

    There are times when you want to retain access to files when running a
    setuid binary, but not when you su, for example. Also, root might want to
    aquire tokens for the running of a particular daemon, but not for general
    use at a root shell. Given an incoming syscall, which identity are the
    requests associated with? Or, in a more applied sense, given an incoming
    syscall, which set of existing RPC2 binds should I use for the request;
    should I open a new Bind, is this identity authorized to access a
    particular file currently in the Venus cache, etc.

    One approach is that processes are in "groups" for the purposes of
    distributed file system identities. Usually people aquire an identity for
    a session, expect different identities for different sessions, etc.
    However, the existing UNIX process groupings have other purposes --
    process groups are used for Job control, and sessions are too fine grained
    (if I run xterm, which will be associated with a new pty, I want to be in
    the same authentication group). And UNIX UID does not seem to be
    sufficient. Hence a new grouping, and that grouping is named the PAG,

    The semantics of PAG-manipulation calls is still up in the air. Thus far,
    the preferred API has merely been newpag() -- the establishment of a new
    pag. Across forks, execs, the PAG is retained. A natural implementation
    of this would be to assign unique PAGids, similar to PIDs, assigning them
    sequentially until wrap-around, and then just avoiding collisions. If a
    process wishes to inherit tokens across a newpag() call, it must retrieve
    a copy of the tokens from Venus before the call, then give them back to
    Venus afterwards (and Venus will know based on the PAG where to store the

    There are issues of garbage collection; we are currently leaning towards
    Venus walking the process list once in a while and garbage collecting its
    old PAGs no longer referred to. This leads to possible attacks by
    processes doing a lot of newpag() calls to wrap around, which is something
    we need to address. I have leant towards the kernel possible providing
    similar structures for storing PAG relationships as it does for process
    groups -- i.e., the normal list, hashing by PAGid to find members, etc,
    and possibly a call-back to Venus of some kind indicating garbage
    collection should occur when the number of members reaches 0.

    This has problems if you wish to use multiple distributed file systems
    (such as AFS and Coda at the same time) which would presumably use the
    same PAGs -- who does the callback go to, etc. There are possible race
    conditions, etc.

    So we do welcome any other solutions to the problem. The PAG seemed to be
    a fairly natural way to do it -- Peter and I hashed out such an idea
    ourselves before discovering that DFS/AFS already had such a mechanism as
    we needed it. Our semantics are almost identical, I believe, although the
    planned implementation is different. If there is a better approach, I
    would greatly appreciate hearing about it.

    Robert N Watson

    Carnegie Mellon University
    SafePort Network Services

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:41    [W:0.023 / U:80.076 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site