[Devel] Re: LXC PIDs, UIDs, and halt

Dwight Schauer dschauer at gmail.com
Mon Oct 19 12:20:51 PDT 2009


On Mon, Oct 12, 2009 at 10:03 AM, Serge E. Hallyn <serue at us.ibm.com> wrote:
> Quoting Dwight Schauer (dschauer at gmail.com):
>> Hi all,
>>
>> I'm new to LXC but have been playing around with it some.
>>
>> I ran into a few issues:
>> 1) PIDs for container processes show up on the controlling host (ps, top,
>> etc). In OpenVZ there is a way to hide them.
>
> Hmm, yes, it's basically by design, and 'fixing' it will sully the
> clean hierarchical pidns design.
>
> The easiest way to emulate that would be to have the host, during
> boot, have init split off two child pid namespaces - one for most of the
> host applications like the xserver, host's sshd, etc, and the other for
> spawning off containers.  Then management of pid namespaces by the
> host has to be done either from the init pid-ns, or from the pid-ns
> which spawns off containers.
<snip>
>> 3) A "kill -9 -1" run from a user in the controlling host kills all
>> processes in all containers where the owner of the process has the same UID
>> as the UID of the outside user. (At least the reverse is not the case).
>
> You can prevent this from happening using selinux or smack.
>
> Properly fixing this requires more work on the user namespace.  I am (as
> always) hoping to get time to work on that soon.
>
<snip>

Well, I more or less solved #1 and #3 for myself by launching my
gnome-session with lxc-execute.

Is there anyway to readily know the id of the PID namespace one is in?
keychain has some issues that I could correct if I could get at the
PID namespace id.

I guess expecting apps like keychain to be namespace aware would be
like expecting them to be "multiverse" aware.

I know I can pass it in through lxc-execute via an environment
variable, but I wondered if there was a more standard way.

-- Dwight
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list