[lxc-users] unprivileged container with systemd?

[Serge Hallyn]

Quoting Dirk Geschke (dirk at lug-erding.de):
> Hi Serge,
> 
> now I started lxcfs within gdb:
> 
> (gdb) where
> #0  0x00007ffff706b610 in __recvmsg_nocancel ()
>     at ../sysdeps/unix/syscall-template.S:82
> #1  0x0000000000403cdd in recv_creds (sock=8, cred=0x7fffffffe5b0, 
>     v=0x7fffffffe5af "1\377\377\377\377\377\377\377\377\377\377\377\377\001")
>     at lxcfs.c:799
> #2  0x00000000004046f2 in do_write_pids (tpid=27028, 
>     contrl=0x60a4c0 "name=systemd", cg=0x60c250 "wheezy/ubuntu-12", 
>     file=0x60bad5 "/cgroup.procs", buf=0x62e920 "1\n") at lxcfs.c:1109

Hm.  What happens here is lxcfs forks a child which jumps
into the container's pidns and listens over a socket for
pids to send back as a struct cred so that the kernel will
xlate into the container's pidns.

It looks like the parent is waiting for the client to send a
cred back.  This really shouldn't happen.  Does 'ps -ef | grep lxcfs'
show that there is only one lxcfs task?

I'd expect this sort of thing before commit 01e718521ab0639ffec091645c0c6eea52ca4f8e
but definately not in 0.5.

> #3  0x0000000000404a16 in cg_write (
>     path=0x60bab0 "/cgroup/name=systemd/wheezy/ubuntu-12/cgroup.procs", 
>     buf=0x7ffff7fd3060 "1\n", size=2, offset=0, fi=0x7fffffffe850)
>     at lxcfs.c:1187
> #4  0x00000000004069b9 in lxcfs_write (
>     path=0x60bab0 "/cgroup/name=systemd/wheezy/ubuntu-12/cgroup.procs", 
>     buf=0x7ffff7fd3060 "1\n", size=2, offset=0, fi=0x7fffffffe850)
>     at lxcfs.c:2016
> #5  0x00007ffff7bb1513 in fuse_fs_write_buf (fs=0x60c040, 
>     path=0x60bab0 "/cgroup/name=systemd/wheezy/ubuntu-12/cgroup.procs", 
>     buf=buf at entry=0x7fffffffe900, off=off at entry=0, fi=fi at entry=0x7fffffffe850)
>     at fuse.c:1878
> #6  0x00007ffff7bb1686 in fuse_lib_write_buf (req=0x60aa20, ino=23, 
>     buf=0x7fffffffe900, off=0, fi=0x7fffffffe850) at fuse.c:3278
> #7  0x00007ffff7bb9209 in do_write_buf (ibuf=0x7fffffffe990, 
>     inarg=<optimized out>, nodeid=<optimized out>, req=<optimized out>)
>     at fuse_lowlevel.c:1300
> #8  fuse_ll_process_buf (data=<optimized out>, buf=0x7fffffffe990, 
>     ch=<optimized out>) at fuse_lowlevel.c:2437
> #9  0x00007ffff7bb588f in fuse_session_loop (se=0x60b720) at fuse_loop.c:40
> #10 0x00007ffff7bade48 in fuse_loop (f=f at entry=0x60bd30) at fuse.c:4313
> #11 0x00007ffff7bbd95f in fuse_main_common (argc=<optimized out>, 
>     argv=<optimized out>, op=<optimized out>, op_size=<optimized out>, 
>     user_data=<optimized out>, compat=<optimized out>) at helper.c:357
> #12 0x0000000000406ccd in main (argc=7, argv=0x7fffffffebe8) at lxcfs.c:2158
> 
> Do you have any idea what is connected to sock=8? lsof does not
> work as long as the fuse mount exist (even so df). So I see the
> lxcfs socket:

yeah the sock=8 presumably is the socketpair created in do_write_pids
to talk to the child we fork.

> # netstat -pan |grep 228936
> unix  3      [ ]         DGRAM                    228936   26992/lxcfs 		@00073
> 
> But what should be on the other side of the socket, hence, what is
> not answering here?
> 
> Best regards
> 
> Dirk
> 
> -- 
> +----------------------------------------------------------------------+
> | Dr. Dirk Geschke       / Plankensteinweg 61    / 85435 Erding        |
> | Telefon: 08122-559448  / Mobil: 0176-96906350 / Fax: 08122-9818106   |
> | dirk at geschke-online.de / dirk at lug-erding.de  / kontakt at lug-erding.de |
> +----------------------------------------------------------------------+