Re: chroot(2) and bind mounts as non-root

From: ebiederm@xmission.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Colin Walters <walters@verbum.org>,
	LKML <linux-kernel@vger.kernel.org>,
	alan@lxorguk.ukuu.org.uk, morgan@kernel.org, luto@mit.edu,
	kzak@redhat.com, Steve Grubb <sgrubb@redhat.com>
Subject: Re: chroot(2) and bind mounts as non-root
Date: Mon, 19 Dec 2011 01:22:31 -0800	[thread overview]
Message-ID: <m1r500j4q0.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20111219040604.GA2205@hallyn.com> (Serge E. Hallyn's message of "Mon, 19 Dec 2011 04:06:04 +0000")

"Serge E. Hallyn" <serge@hallyn.com> writes:

> If I understand you both right, I think what Eric said here is not relevant
> to what Colin cares about.

As long as Colin only cares about being able to be the root user I
agree.  If Colin needs several uids during his build that is trickier.
But it sounds like Colin just needs to have a chroot build environment and
for that a single user sounds good enough.

Being able to use the other namespaces to get a good isolation from the
host environment is also nice and especially the pid namespace can
guarantee that processes won't escape his build environment.

> The mapping Eric is talking about here is new even to me, but I think it
> is an implementation detail referring to a proposal where each uid in the
> container maps to a real uid on the host.  The only thing about that mapping
> that matters is that none of the host uids conflict with existing host
> uids (or uids mapped for other containers).  Now if you want to do cool
> things like map uid 501 on the host to 1001 in the container as well as
> 502 on the host to 1010 in the container, that will be supported - and I
> think that's what Eric is referring to.
>
> But for the sake of fire-off-a-build, you can ignore that and use random
> uids on the host side of the mapping.

It is one of those worse is better implementation details but we can
discuss that more when I start posting patches in January. 

I am not an immediate fan of writing random uids to disk.  Uids being
persistent can be interesting to deal with if those uids are ever
reused.

Right now my implementation supports just 5 non-overlapping uid mapping
ranges.  Which is enough to cover a lot of uids but still fit within one
cacheline.  And I think to keep stat reasonable fast I want at to fit in
a cacheline at least for now.  Oy.  Hopefully it isn't too hard to find
some benchmarks to prove this out.  I expect the torture case is to
time ls -l in a huge directory with a lot of files, owned by a lot of
different users.

Eric