lkml.org 
[lkml]   [2003]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] in-core AFS multiplexor and PAG support
    From
    On Tue, May 13, 2003 at 09:47:59AM -0700, Linus Torvalds wrote:
    > > Maybe... There are arguments either way, but if the token ring is kept in
    > > struct user, a task can't detach from it and pass a token-less set of keys
    > > onto another process it wants to run.
    >
    > Oh, but it can. The pointer should be kept at two places: the "struct
    > task_struct" contains the initial pre-process value, and at file open time
    > that pointer should get copied (and the user count incremented) and put
    > into the "struct file".
    >
    > So you can pass the set of keys the way UNIX _always_ passes rights -
    > through the file descriptor.

    Right, if some process/user opens a file and then passes the descriptor
    to another process/user which closes it. The close should operate under
    the same permissions as the original opener.

    Simple example when this happens is when a setuid application is started
    and the stdout/stderr is redirected to a file. 'ping foo >out 2>&1'. The
    shell opens the file under my uid, but the setuid application closes it
    under the new uid.

    > The advantage of associating the PAG with the real uid rather than make it
    > per-process is that it's a lot easier to administer that way, I think. You
    > don't need to log out or anything like that to have changes take effect
    > for your session, and it is very natural to say "this user now gets key
    > X". Which is what I think you really want when you do something like enter
    > a key to an encrypted filesystem, for example.

    The local user id is not a 'trusted' identity for a distributed filesystem.
    Any user still have to prove his identity by obtaining tokens.

    If someone obtains my user id on in any way (i.e. weak password/
    bufferoverflow/ root exploit), he should not be allowed to use or access
    my tokens as he hasn't proven his identity. In this case he would either
    still be in his original process authentication group, or a new and
    empty PAG. But definitely not in any of my authentication groups.

    Which is also why joining a PAG should never be allowed.

    Any arguments about 'it avoids the cost of obtaining credentials' are
    stupid because that cost is exactly what it takes to prove that a new
    session is in fact associated with a specific user. If our identity
    already was proven beyond reasonable doubt, we clearly already have our
    'token' and the additional cost to associate this with the new PAG is
    zero.

    Jan

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:35    [W:4.169 / U:0.968 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site