Re: [PATCH] private mounts

From: Bodo Eggert
Date: Tue Apr 26 2005 - 15:11:36 EST

On Tue, 26 Apr 2005, Bryan Henderson wrote:

> >> >mknamespace -p users/$UID # (like mkdir -p)
> >> >setnamespace users/$UID # (like cd)
> >> ^^^^^^^^
> >>
> >> You realize that 'cd' is a shell command, and has to be, I hope. That
> >> little fact has thrown a wrench into many of the ideas in this thread.
> >
> >I suppose it will be called by the login process or by wrappers like
> >'nice'.
> 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, except for the fact that no shell does implement a
setnamespace command and therefore can't leave that namespace. If the
shell were actually modified to implement setnamespace, that command would
be exactly like the cd command.

The wrapper I mentioned will usurally not be needed for normal operation,
but if users want additional private namespaces, they'll need this
seperate wrapper (or to modify the application or the shell) in order to
switch into them.

> And it misses one rather
> important requirement compared to mkdir/cd: You can't add a new mount to
> an existing shell.

The mount would be a part of the current namespace, which is shared across
all current user processes unless they are started without login (e.g.
procmail[0]) or running in a different namespace (the user called

[0] If you want procmail in a user namespace, use a wrapper like
exec /usr/bin/setnamespace /users/"$UID" -- /usr/bin/procmail.bin "$@"

BTW: I think the namespaces will need the normal file permissions.

Fun things to slip into your budget
Paradigm pro-activator (a whole pack)
(you mean beer?)
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