On Mon, Jul 01, 2013 at 01:05:23PM +0200, Richard Weinberger wrote: > Am 01.07.2013 12:33, schrieb Daniel P. Berrange: > > On Mon, Jul 01, 2013 at 08:29:14AM +0200, Richard Weinberger wrote: > >> Any ideas what's going on here? > > > > No, it is very odd. It smells like a kernel issue to me. What > > version are you running ? > > I see this issue on all kernels. > Currently I'm using vanilla v3.9.x and v3.10. > > > I've also tried running the demo programs shown on the LWN.net > > article > > > > https://lwn.net/Articles/532593/ > > > > and they don't operate in the way described by the article - the demo > > programs continue to ru as 'nfsnobody' even after the mappings are > > setup. > > > > I'm just using the Fedora 3.9.4-303 kernel, rebuilt with userns enabled > > in KConfig. I'm wondering if there is still stuff missing in 3.9.x > > that prevents this from working properly, or if the kernel behaviour > > changed after those LWN articles were written. > > To me it looks like the capability system behaves odd. > The mappings in /proc are fine as long I do not call capng_updatev(). > Also calling capng_updatev() with parameters that do not change the current > cap set > triggers the odd behavior too. > > So we see two (related?) issues: > 1. If we try updating the capabilities of pid1 /proc/1/ has unmapped files > till we exec(). > 2. Dropping capabilities does not work we always gain a fresh and full > capability set. > > BTW: I'm sure the issues are not caused by Gau Feng's userns patches.
Yeah, I've reproduced this problem with standalone code outside of libvirt. Take the attached code and run # gcc -Wall -o userns_child_exec userns_child_exec.c # ./userns_child_exec -U -M '0 1000 1' -G '0 1000 8' bash Launching child init # id uid=0(root) gid=7(lp) groups=0(root),65534(nfsnobody) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 # ls -al /proc/1/environ -r--------. 1 nfsnobody nfsnobody 0 Jul 1 12:14 /proc/1/environ # cat /proc/1/environ cat: /proc/1/environ: Permission denied and this demo program isn't attempting to touch capabilties at all. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
