LXC PIDs, UIDs, and halt

LXC PIDs, UIDs, and halt

[Dwight Schauer]

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.
2) All controlling host mounts show up in containers.
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).
4) In a opensuse container when I execute "halt" it is not just the
container that halts, but the controlling host as well that shuts down.

It does not make any difference where I mount /proc on the outside into the
container, or from inside the container, the behavior above stays the same.

I'm binding mounting the outside /dev to the container /dev mountpoints.

I'm running Linux 2.6.30.6 and lxc 0.6.3

In opensuse I was able to successfuly start the container only after
commenting out si::bootwait:/etc/init.d/boot in /etc/inittab.
Same for archlinux, I disabled rc::sysinit:/etc/rc.sysinit in /etc/inittab.
I'm not concerned about having to do that.


I'm looking for any insight or needed configuration changes for these issue.

Dwight

Re: LXC PIDs, UIDs, and halt

[Serge E. Hallyn]

Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> 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.

> 2) All controlling host mounts show up in containers.

Same.

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

> 4) In a opensuse container when I execute "halt" it is not just the
> container that halts, but the controlling host as well that shuts down.

Make sure that the container is launched with CAP_SYS_BOOT removed from
the capability bounding set.

> It does not make any difference where I mount /proc on the outside into the
> container, or from inside the container, the behavior above stays the same.
> 
> I'm binding mounting the outside /dev to the container /dev mountpoints.
> 
> I'm running Linux 2.6.30.6 and lxc 0.6.3
> 
> In opensuse I was able to successfuly start the container only after
> commenting out si::bootwait:/etc/init.d/boot in /etc/inittab.
> Same for archlinux, I disabled rc::sysinit:/etc/rc.sysinit in /etc/inittab.
> I'm not concerned about having to do that.
> 
> 
> I'm looking for any insight or needed configuration changes for these issue.

-serge

Re: LXC PIDs, UIDs, and halt

[Dwight Schauer]

On Mon, Oct 12, 2009 at 10:03 AM, Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:

> Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> > 4) In a opensuse container when I execute "halt" it is not just the
> > container that halts, but the controlling host as well that shuts down.
>
> Make sure that the container is launched with CAP_SYS_BOOT removed from
> the capability bounding set.
>

Ok, well it turns out any container can halt the whole system.

If I do:
  capsh --drop="cap_sys_boot" -- -c "lxc-start -n arch-test0"
Then do a halt within the container, the halt still works.
A "reboot" within a container does not reboot the controlling host, the
container runs the shutdown scripts and then idles.

However, if on the controlling host I do:
  capsh --drop="cap_kill" -c "bash --login -i"
Then the subsequent shell can't use kill which I have verified.

Well, these performed on the controlling host:
  capsh --drop="cap_sys_boot" -- -c "halt"
  capsh --drop="cap_sys_boot" -- -c "reboot"

Still halt and reboot my system.

So I know that capabilities are working, I just have not figured out yet how
to prevent containers from being able to halt the controlling host (short of
simply not executing "halt" within a container or renaming/removing "halt"
and "shutdown" but then "init 0" would still work).

CAP_SYS_BOOT seems to control reboot, which has not been an issue, I've not
gotten a container to reboot the controlling host.


Dwight

Re: LXC PIDs, UIDs, and halt

[Serge E. Hallyn]

Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> On Mon, Oct 12, 2009 at 10:03 AM, Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> 
> > Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> > > 4) In a opensuse container when I execute "halt" it is not just the
> > > container that halts, but the controlling host as well that shuts down.
> >
> > Make sure that the container is launched with CAP_SYS_BOOT removed from
> > the capability bounding set.
> >
> 
> Ok, well it turns out any container can halt the whole system.
> 
> If I do:
>   capsh --drop="cap_sys_boot" -- -c "lxc-start -n arch-test0"
> Then do a halt within the container, the halt still works.
> A "reboot" within a container does not reboot the controlling host, the
> container runs the shutdown scripts and then idles.
> 
> However, if on the controlling host I do:
>   capsh --drop="cap_kill" -c "bash --login -i"
> Then the subsequent shell can't use kill which I have verified.
> 
> Well, these performed on the controlling host:
>   capsh --drop="cap_sys_boot" -- -c "halt"
>   capsh --drop="cap_sys_boot" -- -c "reboot"
> 
> Still halt and reboot my system.
> 
> So I know that capabilities are working, I just have not figured out yet how
> to prevent containers from being able to halt the controlling host (short of
> simply not executing "halt" within a container or renaming/removing "halt"
> and "shutdown" but then "init 0" would still work).
> 
> CAP_SYS_BOOT seems to control reboot, which has not been an issue, I've not
> gotten a container to reboot the controlling host.

HAH!  It's upstart, the latest incarnation of init (at least on Fedora).  It
takes commands over an abstract unix domain socket, "
/com/ubuntu/upstart/<pid>".  If you start your container in a new network
namespace, then halt fails.

I haven't gone through the code enough to see exactly how, then,
upstart (in userspace) authorizes the halt request.  Since 'pid'
is encoded in the socket name, i assume it looks at /proc/pid/status.
So it easily could check for CAP_SYS_BOOT \notin pE, or even
check whether it's supposed to be in a container (using some config
files in userspace if somesuch could be agreed upon by everyone, not
really likely).

Oh, yeah, upstart-0.3.11/init/main.c checks whether geteuid()==0.
Wonderful.

-serge

Re: LXC PIDs, UIDs, and halt

[Dwight Schauer]

On Tue, Oct 13, 2009 at 11:02 PM, Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:

> Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> > On Tue, Oct 13, 2009 at 2:59 PM, Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> wrote:
> >
> > > Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> > > > On Mon, Oct 12, 2009 at 10:03 AM, Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> > > wrote:
> > > >
> > > > > Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> > > > > > 4) In a opensuse container when I execute "halt" it is not just
> the
> > > > > > container that halts, but the controlling host as well that shuts
> > > down.
> > > > >
> > > > > Make sure that the container is launched with CAP_SYS_BOOT removed
> from
> > > > > the capability bounding set.
> > > > >
> > > >
> > > > Ok, well it turns out any container can halt the whole system.
> > > >
> > > > If I do:
> > > >   capsh --drop="cap_sys_boot" -- -c "lxc-start -n arch-test0"
> > > > Then do a halt within the container, the halt still works.
> > > > A "reboot" within a container does not reboot the controlling host,
> the
> > > > container runs the shutdown scripts and then idles.
> > > >
> > > > However, if on the controlling host I do:
> > > >   capsh --drop="cap_kill" -c "bash --login -i"
> > > > Then the subsequent shell can't use kill which I have verified.
> > > >
> > > > Well, these performed on the controlling host:
> > > >   capsh --drop="cap_sys_boot" -- -c "halt"
> > > >   capsh --drop="cap_sys_boot" -- -c "reboot"
> > > >
> > > > Still halt and reboot my system.
> > > >
> > > > So I know that capabilities are working, I just have not figured out
> yet
> > > how
> > > > to prevent containers from being able to halt the controlling host
> (short
> > > of
> > > > simply not executing "halt" within a container or renaming/removing
> > > "halt"
> > > > and "shutdown" but then "init 0" would still work).
> > > >
> > > > CAP_SYS_BOOT seems to control reboot, which has not been an issue,
> I've
> > > not
> > > > gotten a container to reboot the controlling host.
> > >
> > > HAH!  It's upstart, the latest incarnation of init (at least on
> Fedora).
> > >  It
> > > takes commands over an abstract unix domain socket, "
> > > /com/ubuntu/upstart/<pid>".  If you start your container in a new
> network
> > > namespace, then halt fails.
> > >
> > > I haven't gone through the code enough to see exactly how, then,
> > > upstart (in userspace) authorizes the halt request.  Since 'pid'
> > > is encoded in the socket name, i assume it looks at /proc/pid/status.
> > > So it easily could check for CAP_SYS_BOOT \notin pE, or even
> > > check whether it's supposed to be in a container (using some config
> > > files in userspace if somesuch could be agreed upon by everyone, not
> > > really likely).
> > >
> > > Oh, yeah, upstart-0.3.11/init/main.c checks whether geteuid()==0.
> > > Wonderful.
> > >
> > > -serge
> > >
> >
> > I'm on archlinux. I don't beleive it is upstart: /sbin/init is owned by
> > sysvinit 2.86-5
> >
> > The following looks like the likely suspect:
> > init         1    root   10u     FIFO               0,14         0t0
> > 1723 /dev/initctl
> >
> > I might be able to fix that with SMACK? I'll look into that tonight.
>
> Ah, you don't have to do that - initctl is a fifo, so as long as you
> make sure not to bind-mount it from the host container it should be
> fine.  If the guest creates it's own, it'll be a different fifo and
> not talk to init.
>
> -serge
>

Yeah, I had been bind mounting all of /dev..... I'm now just mounting the
following:

none   CN_ROOT/dev/pts    devpts    defaults 0 0
none   CN_ROOT/proc    proc    defaults 0 0
none   CN_ROOT/sys    sysfs    defaults 0 0
none   CN_ROOT/dev/shm    tmpfs    defaults 0 0

And I made a minimal CN_ROOT/dev:
crw------- 1 root root 5, 1 2009-10-14 18:36 console
crw-rw-rw- 1 root root 1, 7 2009-10-14 18:35 full
prw------- 1 root root    0 2009-10-14 18:56 initctl
srw-rw-rw- 1 root root    0 2009-10-14 19:09 log
crw-rw-rw- 1 root root 1, 3 2009-10-14 18:35 null
crw-rw-rw- 1 root root 5, 2 2009-10-14 19:11 ptmx
drwxr-xr-x 2 root root    1 2009-10-14 18:35 pts
crw-rw-rw- 1 root root 1, 8 2009-10-14 18:35 random
drwxrwxrwt 2 root root    1 2009-10-14 18:35 shm
crw-rw-rw- 1 root root 5, 0 2009-10-14 18:37 tty
crw-rw-rw- 1 root root 4, 0 2009-10-14 18:35 tty0
crw-rw-rw- 1 root root 1, 9 2009-10-14 18:35 urandom
prw-r----- 1 root adm     0 2009-10-14 19:17 xconsole
crw-rw-rw- 1 root root 1, 5 2009-10-14 18:35 zero

Thanks for the help Serge!

-- Dwight

Re: LXC PIDs, UIDs, and halt

[Serge E. Hallyn]

Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> On Tue, Oct 13, 2009 at 11:02 PM, Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> 
> > Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> > > On Tue, Oct 13, 2009 at 2:59 PM, Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> > wrote:
> > >
> > > > Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> > > > > On Mon, Oct 12, 2009 at 10:03 AM, Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> > > > wrote:
> > > > >
> > > > > > Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> > > > > > > 4) In a opensuse container when I execute "halt" it is not just
> > the
> > > > > > > container that halts, but the controlling host as well that shuts
> > > > down.
> > > > > >
> > > > > > Make sure that the container is launched with CAP_SYS_BOOT removed
> > from
> > > > > > the capability bounding set.
> > > > > >
> > > > >
> > > > > Ok, well it turns out any container can halt the whole system.
> > > > >
> > > > > If I do:
> > > > >   capsh --drop="cap_sys_boot" -- -c "lxc-start -n arch-test0"
> > > > > Then do a halt within the container, the halt still works.
> > > > > A "reboot" within a container does not reboot the controlling host,
> > the
> > > > > container runs the shutdown scripts and then idles.
> > > > >
> > > > > However, if on the controlling host I do:
> > > > >   capsh --drop="cap_kill" -c "bash --login -i"
> > > > > Then the subsequent shell can't use kill which I have verified.
> > > > >
> > > > > Well, these performed on the controlling host:
> > > > >   capsh --drop="cap_sys_boot" -- -c "halt"
> > > > >   capsh --drop="cap_sys_boot" -- -c "reboot"
> > > > >
> > > > > Still halt and reboot my system.
> > > > >
> > > > > So I know that capabilities are working, I just have not figured out
> > yet
> > > > how
> > > > > to prevent containers from being able to halt the controlling host
> > (short
> > > > of
> > > > > simply not executing "halt" within a container or renaming/removing
> > > > "halt"
> > > > > and "shutdown" but then "init 0" would still work).
> > > > >
> > > > > CAP_SYS_BOOT seems to control reboot, which has not been an issue,
> > I've
> > > > not
> > > > > gotten a container to reboot the controlling host.
> > > >
> > > > HAH!  It's upstart, the latest incarnation of init (at least on
> > Fedora).
> > > >  It
> > > > takes commands over an abstract unix domain socket, "
> > > > /com/ubuntu/upstart/<pid>".  If you start your container in a new
> > network
> > > > namespace, then halt fails.
> > > >
> > > > I haven't gone through the code enough to see exactly how, then,
> > > > upstart (in userspace) authorizes the halt request.  Since 'pid'
> > > > is encoded in the socket name, i assume it looks at /proc/pid/status.
> > > > So it easily could check for CAP_SYS_BOOT \notin pE, or even
> > > > check whether it's supposed to be in a container (using some config
> > > > files in userspace if somesuch could be agreed upon by everyone, not
> > > > really likely).
> > > >
> > > > Oh, yeah, upstart-0.3.11/init/main.c checks whether geteuid()==0.
> > > > Wonderful.
> > > >
> > > > -serge
> > > >
> > >
> > > I'm on archlinux. I don't beleive it is upstart: /sbin/init is owned by
> > > sysvinit 2.86-5
> > >
> > > The following looks like the likely suspect:
> > > init         1    root   10u     FIFO               0,14         0t0
> > > 1723 /dev/initctl
> > >
> > > I might be able to fix that with SMACK? I'll look into that tonight.
> >
> > Ah, you don't have to do that - initctl is a fifo, so as long as you
> > make sure not to bind-mount it from the host container it should be
> > fine.  If the guest creates it's own, it'll be a different fifo and
> > not talk to init.
> >
> > -serge
> >
> 
> Yeah, I had been bind mounting all of /dev..... I'm now just mounting the
> following:
> 
> none   CN_ROOT/dev/pts    devpts    defaults 0 0
> none   CN_ROOT/proc    proc    defaults 0 0
> none   CN_ROOT/sys    sysfs    defaults 0 0
> none   CN_ROOT/dev/shm    tmpfs    defaults 0 0
> 
> And I made a minimal CN_ROOT/dev:
> crw------- 1 root root 5, 1 2009-10-14 18:36 console
> crw-rw-rw- 1 root root 1, 7 2009-10-14 18:35 full
> prw------- 1 root root    0 2009-10-14 18:56 initctl
> srw-rw-rw- 1 root root    0 2009-10-14 19:09 log
> crw-rw-rw- 1 root root 1, 3 2009-10-14 18:35 null
> crw-rw-rw- 1 root root 5, 2 2009-10-14 19:11 ptmx
> drwxr-xr-x 2 root root    1 2009-10-14 18:35 pts
> crw-rw-rw- 1 root root 1, 8 2009-10-14 18:35 random
> drwxrwxrwt 2 root root    1 2009-10-14 18:35 shm
> crw-rw-rw- 1 root root 5, 0 2009-10-14 18:37 tty
> crw-rw-rw- 1 root root 4, 0 2009-10-14 18:35 tty0
> crw-rw-rw- 1 root root 1, 9 2009-10-14 18:35 urandom
> prw-r----- 1 root adm     0 2009-10-14 19:17 xconsole
> crw-rw-rw- 1 root root 1, 5 2009-10-14 18:35 zero
> 
> Thanks for the help Serge!

Cool - np at all - and it gave me the heads-up on upstart, use of which
will mean that any container without it's own netns will be able to
poweroff the system.  Urf.

-serge

Re: LXC PIDs, UIDs, and halt

[Dwight Schauer]

On Mon, Oct 12, 2009 at 10:03 AM, Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
>> 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

Re: LXC PIDs, UIDs, and halt

[Serge E. Hallyn]

Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> On Mon, Oct 12, 2009 at 10:03 AM, Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> > Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> >> 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.

No, because pid namespaces don't actually have an id.

What exactly are the keychain issues?  So far the keychain/namespacing
handling is very basic (new user-namespace = new set of keyrings), bc
there really weren't any user requirements to draw on yet.

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

Well if there is a clean and safe way to do it (whatever 'it' is) through
environment variable all the better, then we can avoid kernel changes.
But if you need kernel help pls let us know.

-serge

Re: LXC PIDs, UIDs, and halt

[Dwight Schauer]

On Mon, Oct 19, 2009 at 5:24 PM, Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
>> On Mon, Oct 12, 2009 at 10:03 AM, Serge E. Hallyn <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
>> > Quoting Dwight Schauer (dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
---< snip >---
>> 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.
>
> No, because pid namespaces don't actually have an id.
>
> What exactly are the keychain issues?  So far the keychain/namespacing
> handling is very basic (new user-namespace = new set of keyrings), bc
> there really weren't any user requirements to draw on yet.
>
>> 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.
>
> Well if there is a clean and safe way to do it (whatever 'it' is) through
> environment variable all the better, then we can avoid kernel changes.
> But if you need kernel help pls let us know.
>
> -serge
>

Ok, the issue is that what is stored in the file that keychain
produces is based on PID
When logging into a different PID namespace that file is considered
stale, because there is not an agent at that pid, so the file is
overwritten by keychain.

I'd to modify the filename to have the current namespace name (passed
in via environment variable) be part of it, so that the proper one is
checked by keychain and sourced by my shell

It would require a keychain change either way, whether I'd use an
environment variable or something was done to the kernel to allow it
to be retrieved.

A lot of applications that base things off a PID stored in a file will
have issues when multiple PID namespaces are in play, and where those
files are in the same locations in each container.

I'm not asking for any kernel help, an environment variable will suffice.

I'll patch keychain, and once I've determined it works correctly, I'll
see if the maintainers (The Funtoo folk) will accept the patch.

-- Dwight

Re: LXC PIDs, UIDs, and halt

[Dwight Schauer]

On Tue, Oct 20, 2009 at 8:04 PM, Dwight Schauer <dschauer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
----< snip >---
> Ok, the issue is that what is stored in the file that keychain
> produces is based on PID
> When logging into a different PID namespace that file is considered
> stale, because there is not an agent at that pid, so the file is
> overwritten by keychain.
>
> I'd to modify the filename to have the current namespace name (passed
> in via environment variable) be part of it, so that the proper one is
> checked by keychain and sourced by my shell
>
> It would require a keychain change either way, whether I'd use an
> environment variable or something was done to the kernel to allow it
> to be retrieved.
>
> A lot of applications that base things off a PID stored in a file will
> have issues when multiple PID namespaces are in play, and where those
> files are in the same locations in each container.
>
> I'm not asking for any kernel help, an environment variable will suffice.
>
> I'll patch keychain, and once I've determined it works correctly, I'll
> see if the maintainers (The Funtoo folk) will accept the patch.
>
> -- Dwight
>

Ok, I think I can just use the --host option, no need to patch.