[lkml]   [2005]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] private mounts
    Al Viro wrote:
    > > > I believe the point is:
    > > >
    > > > 1. Person is logged from client Y to server X, and mounts something on
    > > > $HOME/mnt/private (that's on X).
    > > >
    > > > 2. On client Y, person does "scp X:mnt/private/secrets.txt ."
    > > > and wants it to work.
    > > >
    > > > The second operation is a separate login to the first.
    > >
    > > Solution?
    > ... is the same as for the same question with "set of mounts" replaced
    > with "environment variables".

    Not quite.

    After changing environment variables in .profile, you can copy them to
    other shells using ". ~/.profile".

    There is no analogous mechanism to copy namespaces.

    I agree with you that Miklos' patch is not the right way to do it.

    Much better is the proposal to make namespaces first-class objects,
    that can be switched to. Then users can choose to have themselves a
    namespace containing their private mounts, if they want it, with
    login/libpam or even a program run from .profile switching into it.

    While users can be allowed to create their own namespaces which affect
    the path traversal of their _own_ directories, it's important that the
    existence of such namespaces cannot affect path traversal of other
    directories such as /etc, or /autofs/whatever - and that creation of
    namespaces by a user cannot prevent the unmounting of a non-user
    filesystem either.

    The way to do that is shared subtrees, or something along those lines.

    Here is one possible implementation:

    As far as I can tell, namespaces are equivalent to predicates attached
    to every mount - the predicate being "this mount intercepts path
    traversal at this point if current namespace == X".

    It makes sense, when users can create namespaces for themselves, that
    the predicate be changed to "this mount valid if [list of current
    namespace and all parent namespaces] contains X". Parent namespace
    means the namespace from which a CLONE_NS namespace inherits.

    Then it would be safe (i.e. secure) to allow ordinary users to use
    CLONE_NS for the purpose of establishing private namespace(s), within
    which they can mount things on directories they own. But those users
    would continue to see mounts & unmounts done by the system in other
    directories such as /mnt and /autofs. Effectively this confines the
    new namespace to only affecting directories owned by the user.

    That would work properly with suid programs, properly with autofs and
    also manual system-wide administration, and it is general enough that
    it doesn't force any particular policy. Also, it would be usable for
    partial sharing of resources in virtual server and chroot scenarios.
    What's not to like? :)

    -- Jamie
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-04-24 23:42    [W:0.021 / U:119.684 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site