Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call

[Jamie Lokier <jamie@shareable.org>]

Christoph Hellwig wrote:
> > The problem is the current mechanism _forces_ the user to have
> > different environments on the same box - there's no choice.
> > 
> > Which is, as Al says, just like environment variables.
> > 
> > But not like files - if I create a file called $HOME/foo, I expect
> > that I can access it from a different login.  I might want to have
> > different environments, but that's not the _default_ when dealing with
> > files.
> > 
> > The question is whether private user-mounts should, by default, behave
> > more like environment variables or more like files.
> 
> I think you're a little confused.

No, I'm not.

Here's a perhaps more illustrative example.  My bookmarks in
~/.ncftp/bookmarks are not per session, they're per user.  They're not
"global" as in shared by all users in the usual sense.  (Yes, the file
is in a shared namespace, but other users won't be using it when they
type "ncftp".)

The _concept_ "my Ncftp bookmarks" is per-user, and bookmarks created
in one session are immediately usable in another session.

That's what I mean when I say "more like files".

Environment variables are not like that, bookmarks are.

Rephrasing the question: The question is whether private user-mounts
should, by default, behave more like environment variables or more
like bookmarks.

It's a user interface question, not a technical question.  Understand?

I think the user interface is more intuitive when private user-mounts
appear across all sessions shared by the same user.  That doesn't
preclude a non-default option to turn that off.

And here's _why_ I think that's more intuitive: people expect things
which appear in the filesystem to be visible across all sessions.
User-mounts certainly are visible in the filesystem.

> Files are a global ressource and as
> such it makes sense to see them everywhere.

No, files are not seen everywhere, as evidenced by the existence of
namespaces...  They're seen everywhere within a particular namespace.
And that namespace is determined by userspace policy...

> But you're not arguing for making the namespace a global ressource
> (again), but a per-user one, which has no precedence.

As a user interface, it has the precedence of bookmarks, cookies,
options in dotfiles...

I am arguing for making namespaces a global resource, which can be
joined and accessed by userspace however it likes.

Which makes it a policy entirely settable by userspace tools.

(And /proc/NNN/root is _very_ close to providing that.  It seems that
it just works as expected when the permission checks are removed).

The fact that I'd personally use namespaces in a per-user way is a
policy decision.  I use ssh-agent in a per-user way too, but that's my
choice, and other users can use it however they want.

-- Jamie