Re: [PATCH] private mounts

[Bodo Eggert <7eggert@gmx.de>]

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/