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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list