[lkml]   [2011]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: chroot(2) and bind mounts as non-root
    "Serge E. Hallyn" <> 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

    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.


     \ /
      Last update: 2011-12-19 10:23    [W:0.024 / U:1.744 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site