[libvirt] [PATCH] util: Call capng_setpid() before using cap-ng
audit is using cap-ng itself since version 2.6.1, and it gets to initialize the internal state of the cap-ng library before we call fork(). Because of that, our own use of cap-ng in the child process ends up attempting to change the capabilities of the parent process instead of the child process, which fails. Calling capng_setpid() before using any other cap-ng API ensures we're altering the capabilities of the right process. --- src/util/virutil.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/util/virutil.c b/src/util/virutil.c index 170dd59..d393a12 100644 --- a/src/util/virutil.c +++ b/src/util/virutil.c @@ -1465,6 +1465,14 @@ virSetUIDGIDWithCaps(uid_t uid, gid_t gid, gid_t *groups, int ngroups, bool need_setgid = false, need_setuid = false; bool need_setpcap = false; + /* The cap-ng library stores some internal data in a thread local + * variable; that includes the PID of the process it should alter + * the capabilities of. After fork(), this data is not cleared, + * so we might end up trying to change the capabilities of a + * different process. Initialize the PID explicitly to work around + * that issue */ + capng_setpid(getpid()); + /* First drop all caps (unless the requested uid is "unchanged" or * root and clearExistingCaps wasn't requested), then add back * those in capBits + the extra ones we need to change uid/gid and -- 2.7.4
On Fri, Jul 01, 2016 at 04:30:44PM +0200, Andrea Bolognani wrote:
audit is using cap-ng itself since version 2.6.1, and it gets to initialize the internal state of the cap-ng library before we call fork(). Because of that, our own use of cap-ng in the child process ends up attempting to change the capabilities of the parent process instead of the child process, which fails.
Calling capng_setpid() before using any other cap-ng API ensures we're altering the capabilities of the right process.
I really don't want to do any hack workaround in libvirt until we've got feedback from the cap-ng maintainers, as I think it is really their bug to fix. Regards, 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 :|
On Fri, Jul 01, 2016 at 03:33:07PM +0100, Daniel P. Berrange wrote:
On Fri, Jul 01, 2016 at 04:30:44PM +0200, Andrea Bolognani wrote:
audit is using cap-ng itself since version 2.6.1, and it gets to initialize the internal state of the cap-ng library before we call fork(). Because of that, our own use of cap-ng in the child process ends up attempting to change the capabilities of the parent process instead of the child process, which fails.
Calling capng_setpid() before using any other cap-ng API ensures we're altering the capabilities of the right process.
I really don't want to do any hack workaround in libvirt until we've got feedback from the cap-ng maintainers, as I think it is really their bug to fix.
FYI, I attached a patch for libcap-ng whic uses pthread_atfork to reset their global state https://bugzilla.redhat.com/show_bug.cgi?id=1352064 It works with my demo program, but haven't tested with libvirt yet Regards, 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 :|
On Fri, Jul 01, 2016 at 04:30:44PM +0200, Andrea Bolognani wrote:
audit is using cap-ng itself since version 2.6.1, and it gets to initialize the internal state of the cap-ng library before we call fork(). Because of that, our own use of cap-ng in the child process ends up attempting to change the capabilities of the parent process instead of the child process, which fails.
Calling capng_setpid() before using any other cap-ng API ensures we're altering the capabilities of the right process. --- src/util/virutil.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/src/util/virutil.c b/src/util/virutil.c index 170dd59..d393a12 100644 --- a/src/util/virutil.c +++ b/src/util/virutil.c @@ -1465,6 +1465,14 @@ virSetUIDGIDWithCaps(uid_t uid, gid_t gid, gid_t *groups, int ngroups, bool need_setgid = false, need_setuid = false; bool need_setpcap = false;
+ /* The cap-ng library stores some internal data in a thread local + * variable; that includes the PID of the process it should alter + * the capabilities of. After fork(), this data is not cleared, + * so we might end up trying to change the capabilities of a + * different process. Initialize the PID explicitly to work around + * that issue */ + capng_setpid(getpid()); + /* First drop all caps (unless the requested uid is "unchanged" or * root and clearExistingCaps wasn't requested), then add back * those in capBits + the extra ones we need to change uid/gid and
I'll only note that I tested (effectively) this patch earlier today and it worked for me. Can you also link to the bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1351995 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
participants (3)
-
Andrea Bolognani -
Daniel P. Berrange -
Richard W.M. Jones