Messages in this thread | | | Date | Wed, 12 Oct 2011 15:04:52 -0400 | From | "J. Bruce Fields" <> | Subject | Re: Detecting if you are running in a container |
| |
On Wed, Oct 12, 2011 at 02:25:04PM -0400, Kyle Moffett wrote: > On Wed, Oct 12, 2011 at 13:57, J. Bruce Fields <bfields@fieldses.org> wrote: > > On Tue, Oct 11, 2011 at 02:16:24PM -0700, Eric W. Biederman wrote: > >> Where all of this winds up interesting in the field of oncoming kernel > >> work is that uids are persistent and are stored in file systems. So > >> once we have all of the permission checks in the kernel tweaked to care > >> about user namespaces we next look at the filesystems. The easy > >> initial implementation is going to be just associating a user namespace > >> with a super block. But farther out being able to store uids from > >> different user namespaces on the same filesystem becomes an interesting > >> problem. > > > > Yipes. Why would anyone want to do that? > > Consider an NFS file server providing collaborative access to multiple > independently managed domains (EG: several different universities), > each with their own LDAP userid database and Kerberos services. > > The common server is in its own realm and allows cross-realm > authentication to the other university realms, using the origin realm > to decide what namespace to map each user into. > > If you are just doing read-only operations then you don't need any > kind of namespace persistence on the NFS server's storage. On the > other hand, if you want to allow users to collaborate and create ACLs > then you need something dramatically more involved.
Yeah, OK, I suppose I'd imagined mapping into the server's id space somehow for that case, but I suppose this would be cleaner. Still, seems like a big pain....
> On the wire, the kerberos server would simply identify each NFSv4 ACL > entry with a particular realm ID, but in the backend it would need > some filesystem-level disambiguation (possibly the recently-proposed > RichACL features?)
That doesn't help with owner and group.
--b. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |