linux-kernel - Re: Detecting if you are running in a container

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGZ=bqJxadNqaPCW3HufrMmQ57x082=pCDa6-mWLsdtfxHgdPw@mail.gmail.com>
Date:	Wed, 12 Oct 2011 14:25:04 -0400
From:	Kyle Moffett <kyle@...fetthome.net>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Theodore Tso <tytso@....edu>,
	Matt Helsley <matthltc@...ibm.com>,
	Lennart Poettering <mzxreary@...inter.de>,
	Kay Sievers <kay.sievers@...y.org>,
	linux-kernel@...r.kernel.org, harald@...hat.com, david@...ar.dk,
	greg@...ah.com, Linux Containers <containers@...ts.osdl.org>,
	Linux Containers <lxc-devel@...ts.sourceforge.net>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Daniel Lezcano <daniel.lezcano@...e.fr>,
	Paul Menage <paul@...lmenage.org>
Subject: Re: Detecting if you are running in a container

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

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/