[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4DBD2EBA-9AE2-4598-A9E5-FE7ADCA60B44@mac.com>
Date: Sat, 15 Jul 2006 00:35:34 -0400
From: Kyle Moffett <mrmacman_g4@....com>
To: ebiederm@...ssion.com (Eric W. Biederman)
Cc: Trond Myklebust <trond.myklebust@....uio.no>,
Dave Hansen <haveblue@...ibm.com>,
"Serge E. Hallyn" <serue@...ibm.com>,
Cedric Le Goater <clg@...ibm.com>,
linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>,
Kirill Korotaev <dev@...nvz.org>, Andrey Savochkin <saw@...ru>,
Herbert Poetzl <herbert@...hfloor.at>,
Sam Vilain <sam.vilain@...alyst.net.nz>
Subject: Re: [PATCH -mm 5/7] add user namespace
On Jul 15, 2006, at 00:09:50, Eric W. Biederman wrote:
> Trond Myklebust <trond.myklebust@....uio.no> writes:
>> NFS is the least of your problems. You can only have one
>> superblock for most local filesystems too and with good reason:
>> imagine, for instance, the effect of having 2 different block
>> allocators working on the same device.
>
> Let me try to explain the idea again.
>
> Currently there is a global context in which we interpret uids.
> But different machines can have different global contexts.
>
> Each filesystem to be sane needs to store uids from only one such
> context. For network filesystems typicall the context is extended
> to multiple machines so that everyone who mounts a filesystem will
> interpret a uid with the same meaning.
>
> The idea of creating multiple a user id namespaces on a single
> machine creates multiple contexts for the interpretation of uid
> values on the same machine. Allowing a single id to refer to
> different users depending on the context in which it is interpreted.
>
> I can think of no circumstance in which a single filesystem will
> have multiple contexts in which user id's will be interpreted. Nor
> can I think of a sane scenario in which that would occur.
>
> Given the fact that we are referring to a global property of a
> filesystem why is it fundamentally a problem to put it in the
> superblock?
Here's a possible example:
I have one disk which I want to share between multiple virtualized
instances for root filesystems. I bind-mount /onedisk/foo as the foo
virtual machine's root and /onedisk/bar as the bar virtual machine's
root. There should (must) be two interpretations of the linear UID
space on that disk, one for the foo virtual machine, and one for the
bar virtual machine. By allowing the administrator to determine UID
namespace per-vfsmount, you make such an arrangement possible where
it otherwise would not be.
With NFS and the proposed superblock-sharing patches (necessary for
efficiency and other reasons I don't entirely understand), the
situation is worse: A mount of server:/foo/bar on / in the bar
virtual machine may get its superblock merged with a mount of server:/
foo/baz on / in the baz virtual machine. If it's efficient to merge
those superblocks we should, and once again it's necessary to tie the
UID namespace to the vfsmount, not the superblock.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists