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

[Daniel Lezcano]

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