[lxc-devel] Quick questions and feedback about `lxc-start`

Ciprian Dorin, Craciun ciprian.craciun at gmail.com
Sat Jan 9 19:23:51 UTC 2010


On Sat, Jan 9, 2010 at 8:45 PM, Andrian Nord <nightnord at gmail.com> wrote:
> On Sat, Jan 09, 2010 at 07:16:47PM +0200, Ciprian Dorin, Craciun wrote:
>>     Indeed I want the feature for non-root access to the filesystem.
>> My current usage for which I've tested LXC is to build ArchLinux
>> packages, in a new environment (freshly installed from packages)
>> uncontaminated by my configurations and packages that I've manually
>> installed. So when inside the container I would like to be able to
>> compile the package as non-root.
>
> Err... Gentoo uses sandbox for that, but it's hacky. Maybe you better
> want to just mount --bind -o ro system dirs and run in chroot than?

    Yes a simple `chroot` will suffice, but then again where's the
fun? (But also see below.)

    One problem that I encounter is the following:
~~~~~~~~
cd /tmp # tmp is on a tmpfs file system
mkdir test
mkdir test-backing
sudo mount --bind ./test-banking ./test -o ro
touch ./test/a
# shouldn't it give me an error about creating that file in the `ro` bind?
~~~~~~~~

    So what I'm doing wrong here? (I can't guess...)


> It could be done by both lxc-execute and lxc-start, I suppose.
>
> Still, that's a good point, if you trust packages you are building, but
> want to control resources and protect yourself from broken
> build-systems, without much isolating.

    And security is not the only plus. Imagine you want `lxc-freeze`
that GCC compiling, and do something important now, then resuming.
(Without the freezing feature it's almost impossible.)
    (By the way, I've not thought about limiting the resources
available for the build system.)

    (Indeed I should have used `lxc-execute` instead of `lxc-start`...)


>>     Also other usages for the non-root user, would be (at least to
>> me), testing new applications to which you don't trust the code. (For
>> example evaluating assignments from students, and I'm not sure what
>> they put inside makefiles or what the resulting application might do.)
>>     And in this case I don't feel to good about letting the untrusted
>> code run as root (even tough it doesn't have the needed capabilities),
>> because after the container exists, the files created still remain on
>> the file system...
>
> 'rm -Rf' you are wondering about, runned without root rights may not
> destroy your system, but may damage vital data, anyway. Probably this
> should be done in chroot with read-only bind to be really safe. But if
> you are wondering just about resources and lightly about
> filesystem-access it's also a good point.

    The problem with a `ro` mount is that at some point I should be
able to write something somewhare (I want also the build to be done
inside the `jail`)...

    (But unfortunately I was referring more to the filesystem access
than to the resource limiting... :) )


>>     Now from what I've quickly read in the source code, the difference
>> between `lxc-execute` and `lxc-start`, is that `lxc-execute` uses
>> `lxc-init` (an init like process that collects orphan processes). So
>> my question is: except orphan process collection, does `lxc-init` do
>> something else (special, etc.)?
>
> Currently - no. In future, it is supposed to also run applications as
> asked from hostspace, and it would be forked inside full-system
> containers also, just as not-init process.

    Interesting... This is like in the case of vserver where I'm able
to enter another domain.


> lxc-start is for starting full-system containers, I suppose, so,
> probably, it's not making much sense currently.

    Indeed with `lxc-start` it would not make much sense, but then
again one cool usage of LXC would be development of new init-like
applications. Or allowing services to be run under the supervision of
applications like runit (mainly runsv), and thus the runsv should
behave just a little bit like an init-process, but without the root
access.


>>     P.S.: Also what I'm requesting (choosable user / group for the new
>> process) could also be applied to `lxc-execute`.
>
> I suppose it's impossible for lxc-start, as it's supposed to run
> /sbin/init like scripts, that require root (at least sysvinit does), but
> lxc-execute may have such feature.

    Ok.


> But i'm not very sure, how to
> implement this... Err... It's not very nice, but simpliest way I see, is
> to just call 'su - -c "command" user' transparently, as there is much things
> to handle, starting from pam (to have env set correctly), but this may not
> work on all configurations (but on 99,9% of them).

    Indeed there are a couple of solutions:
    * `su`, `sudo`, or su-like wrappers -- the problems with these is
that they're required to exist inside the container, which is
something I don't particularly like. (I would prefer to have inside
the container only the needed executables.)
    * `setuid` / `setgid` -- I would prefer this because it's
simplicity; also `lxc-execute` is somehow low-level, and thus it
shouldn't concern itself with translating from username to UID, etc.;
it shall be the callers job (usually another wrapping script) that
should resolve the username, and that should ensure the proper
environment is set; (one thing I'm not sure of is what to do with the
supplementary groups; maybe they should be also settable;)

> Maybe it would be simplier just to have shell wrapper, that will do this
> (i.e. replace exec with su call)?

    See above.




More information about the lxc-devel mailing list