lkml.org 
[lkml]   [2006]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH -mm 5/7] add user namespace
    Date
    Cedric Le Goater <clg@fr.ibm.com> writes:

    > Eric W. Biederman wrote:
    >
    >>> I think user namespace should be unshared with filesystem. if not, the
    >>> user/admin should know what is doing.
    >>
    >> No. The uids in a filesystem are interpreted in some user namespace
    >> context. We can discover that context at the first mount of the
    >> filesystem.
    >
    > ok. so once you're in such a user namespace, you can't unshare from it
    > without loosing access to all your files ?

    Any file that is accessible without needing specific user and group
    permissions will still be accessible. In essence you are an enhanced
    version of the nobody user when you access files outside of your
    namespace. What you can't do is create files as you cannot be
    represented on the filesystem.

    >> Assuming the uids on a filesystem are the same set of uids your process
    >> is using is just wrong.
    >
    > well, this is what is currently done without user namespaces.

    Yes. But the whole system is assumed to be in the same user namespace,
    so that is a reasonable assumption. Once we break that assumption we
    need to do something different. There are a few network filesystems
    that are at least working on using keys to authenticate users.

    >>>> I believe some of the key infrastructure which is roughly kerberos
    >>>> authentication tokens could be used for this purpose.
    >>> please elaborate ? i'm not sure to understand why you want to use the keys
    >>> to map users.
    >>
    >> keys are essentially security credentials for something besides the
    >> local kernel. Think kerberos tickets. That makes the keys the
    >> obvious place to say what uid you are in a different user namespace
    >> and similar things.
    >
    > what about performance ? wouldn't that slow the checking ?

    It needs to be looked at, but it shouldn't slow the same namespace
    case, and permission checking is largely a slow path issue. So a little
    overhead at open time is preferred to overhead after you get the file
    open.

    Mapping users is clearly a separate problem, but related problem. For
    sharing read-only data that you don't mind sharing with everyone the
    current set of semantics I have described is fine.

    Eric
    -
    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: 2006-07-13 20:03    [W:4.078 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site