Re: Detecting if you are running in a container

[Kyle Moffett]

On Wed, Oct 12, 2011 at 13:57, J. Bruce Fields <bfields@xxxxxxxxxxxx> 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.

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?)

Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/