lkml.org 
[lkml]   [2005]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] private mounts
    On Tue, 26 Apr 2005, Bryan Henderson wrote:

    > >> Just to be clear, then: this idea is fundamentally different from the
    > >> mkdir/cd analogy the thread starts with above.
    > >
    > >NACK, it's very similar to the cd "$HOME" (or ulimit calls) done by the
    > >login mechanism,
    >
    > That's not a NACK. The cd "$HOME" and ulimit calls done by the login
    > process (more precisely, by a shell profile) are quite different from the
    > mkdir/cd the thread started with. Who creates a new directory in his
    > shell profile?

    I create a directory in /tmp and set $TMP to that directory, because I
    can't just mount a private tmpfs. But that's another topic.

    > I assume the mkdir/cd analogy is a case of a person doing
    > a mkdir and cd in a running shell. (That is indeed analogous to what one
    > would like to do with a private mount).

    ACK, with respect to lifetime and processes affected, it will be exactly
    like creating/using a directory in a tmpfs. But as you noticed, you'd need
    the shell builtin command to make this analogy complete. That's not going
    to happen, but it's not needed for operation.

    > When you said "by the login process or by wrappers like nice," in response
    > to my pointing out that setnamespace would need to be a shell builtin
    > command, I assumed you were talking about putting it in the code that
    > execs the shell as opposed to in the shell profile, thus eliminating the
    > need for a shell builtin.

    Exactly. You can't patch all login daemons, so you'll need pam to do the
    initial setup.

    After that, the users may decide to ignore having a private namespace (it
    will just DTRT), or they can decide to use that feature to lock in some of
    their programs. Obviously pam won't allow private sub-namespaces at random
    times, while the general system call would support this, and their shell
    won't do that, too. In the same way you'll need a wrapper like "#!/bin/sh
    cd $dir&&exec $prog" for doing the initial chdir on behalf of
    chdir-ignorant programs, you'll need a wrapper for setnamespace-ignorant
    programs. The only difference is that chdir-ignorant programs are rare.

    > But the important thing is just to recognize, as you say explicitly now,
    > that setnamespace has to be shell builtin command for
    > setnamespace/mknamespace to be analogous to mkdir/cd. That was my
    > original statement, if somewhat indirect:

    For the analogy yes, for usage no.
    --
    The secret of the universe is #@*%! NO CARRIER
    -
    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-04-27 10:23    [W:2.701 / U:1.256 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site