On Wed, Oct 12, 2011 at 02:25:04PM -0400, Kyle Moffett wrote: > On Wed, Oct 12, 2011 at 13:57, J. Bruce Fields <bfie...@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. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
