"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 Iagree. If Colin needs several uids during his build that is trickier.But it sounds like Colin just needs to have a chroot build environment andfor that a single user sounds good enough.Being able to use the other namespaces to get a good isolation from thehost environment is also nice and especially the pid namespace canguarantee 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 candiscuss that more when I start posting patches in January. I am not an immediate fan of writing random uids to disk. Uids beingpersistent can be interesting to deal with if those uids are everreused.Right now my implementation supports just 5 non-overlapping uid mappingranges. Which is enough to cover a lot of uids but still fit within onecacheline. And I think to keep stat reasonable fast I want at to fit ina cacheline at least for now. Oy. Hopefully it isn't too hard to findsome benchmarks to prove this out. I expect the torture case is totime ls -l in a huge directory with a lot of files, owned by a lot ofdifferent users.Eric