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

[Andrian Nord]

On Sat, Jan 09, 2010 at 09:23:51PM +0200, Ciprian Dorin, Craciun wrote:
>     Yes a simple `chroot` will suffice, but then again where's the
> fun? (But also see below.)

Nonono, you may just start lxc container with lxc.rootfs specified - it
will do chroot (and maybe even pivot_root with latest commits, for
enchanced security)

> ~~~~~~~~
> 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...)

I've asked this before, but with no luck. lxc has nothing with it, I
suppose - all is done correctly, I've checked this. Probably this should
be reported as kernel bug, if it is still unknown (but I suppose it's
known already).

Yeap, that's a flaw, but let's consider, that it would be fixed.
Someday.

>     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.)

Eh... I'm using ctrl+z for this. Works quite flawlessly, on Gentoo it's
required very often, you know =)

>     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`)...

Yeap. You want to
a) Have all your system libraries in place
b) Have compilation and installation made in some other place, to be
save from possible failtures
c) Test and probably move good build to your live system.

a) b) and c-test-part) could be done inside container with most of
system folders binded, but with compilation inside some non-ro dir,
/var/tmp, for example. Maybe even tmpfs for speed. See how Gentoo does
this.

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

ACL? Ok, that's overkill, I suppose =)

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

I don't know vserver, it's like vzctl exec from openvz. But, still, it's
implemented only partially now.

>     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.

For init-like you 100% don't need to run this on your host's root. It would
be unreal testcase with non-root gid, you will kill whole idea of such testing.

For supervising... I dunno, really, I would just make another
full-system container or application container in chroot, maybe tmpfs -
it many of free ram on server.

>     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.)

Good point. For application containers it's useless.

>     * `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;)

I'm not sure, but chmod +s? It could be done from host before launching,
and then reverted back. This should done the trick. Still, there is
possibility of just changing uid, as many daemons doing, but I'm
wondering about shells. Probably this should be tested with chmod +s
before (in theory, effect should be the same), and if this works
correctly - it could be done after spawning process.