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

[Andrian Nord]

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?

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

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

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

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

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