[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-fsdevel
Subject: Re: [RFC][2.6 patch] Allow creation of new namespaces during mount system call
From: Jamie Lokier <jamie () shareable ! org>
Date: 2005-04-30 15:01:11
Message-ID: 20050430150111.GB4362 () mail ! shareable ! org
[Download RAW message or body]
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
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic