Re: [PATCH] private mounts

From: Bodo Eggert
Date: Wed Apr 27 2005 - 03:21:04 EST

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@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at