[lxc-devel] Quick questions and feedback about `lxc-start`
Daniel Lezcano
dlezcano at fr.ibm.com
Sun Jan 10 04:13:42 UTC 2010
Ciprian Dorin, Craciun wrote:
> On Sat, Jan 9, 2010 at 6:31 PM, Andrian Nord <nightnord at gmail.com> wrote:
>>> It's not very clear to me if the new patches would provide
>>> something like I have proposed:
>>> sudo -- lxc-start --name test --rcfile ./name.conf --uid "$UID"
>>> --gid "$GID" -- /bin/bash
>> Ahh. Sorry, I saw lxc-start and thought that you are talking about
>> full-system containers. For application containers it would be
>> better to use lxc-execute, maybe?
>>
>> If you need exactly changing pid into new spawned namespace, I wounder
>> why. Situation when two users with same uid in different user namespaces
>> are equal isn't correct and is object for change, I suppose. Or this is
>> for security reasons (to make root non-root, to protect filesystem)?
>
> 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.
Maybe I am misunderstanding but you can do that no as the lxc-setcap
gives enough privilege to the lxc commands letting a non-root user to
spawn a container (user won't have any privilege in the container).
> 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...
>> For application containers it would be
>> better to use lxc-execute, maybe?
>
> 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.)?
It allows to support daemons in the container because the pid namespace
implementation makes a pid 1 dying to kill all the processes, so when
the application daemonize (httpd, sshd), the container dies. The
lxc-init is the pid 1 and it stays there avoiding such situation.
> P.S.: Also what I'm requesting (choosable user / group for the new
> process) could also be applied to `lxc-execute`.
>
> P.P.S: As I've said, if you think this feature would be useful
> (and acceptable to inclusion in upstream) I could provide the patches.
> I don't expect someone else doing my homework... :)
>
More information about the lxc-devel
mailing list