The recent version of libcap caused a build breakage of fakeroot package, as reported in openSUSE bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1162014 It seems failing at xattr testing. As far as I read the code, it performs: setcap cap_net_raw+ep $tmp/foo; getcap $tmp/foo in the fakeroot. The expected output should be "^$tmp/foo = cap_net_raw+ep" but the result seems to be an empty string. My colleague suggested that the override support (commit b2b267ef1c83f1f3d3105a4bb84f8bebbc130dec) started showing the regression. The report above showed libcap 2.30, but also 2.31 was tested locally and failed, too.
In the libcap build tree: $ make clean $ make $ cd progs/ $ sudo ./setcap cap_net_raw+ep capsh $ ./getcap capsh capsh = cap_net_raw+ep $ ./capsh --print | grep Current Current: = cap_net_raw+ep I have tried this with the pristine sources for these tags: libcap-2.XX and XX = 31,30,29,28. As such, I cannot reproduce your stated problem. Are you invoking 'setcap' as root? What happens if you try: setcap cap_net_raw+ep $tmp/foo && echo all set && getcap $tmp/foo Are you linking setcap statically or dynamically? libcap defaults the build to static. If you are linking it dynamically, "in the fakeroot" does ldd setcap correctly find the needed library? Do you have any error output?
Honestly speaking, I'm not familiar with the target package, but my understanding is that it's "fakeroot", so it does run the thing inside without sudo & co. That said, it should be checked with fakeroot, not with sudo. I can confirm that the normal root works on my system locally. The fakeroot package is built with libcap shared lib, AFAIK. It's a regression in rpm package build, i.e. replacing libcap.so.2 with the newer one caused a problem at fakeroot build test phase running the test above.
I've just been looking at the fakeroot package sources. I had no idea such a thing existed. It seems that it assumes that glibc is the sole wrapper for system calls, and appears to be intercepting them itself. Since recent libcap sources avoid glibc mediated syscalls, in order to support POSIX semantics for setting capabilities, it is not surprising that things break. I'll take a look and see if I can find a middle path. At present, I believe libcap builds from 2.28+ will be problematic: https://sites.google.com/site/fullycapable/release-notes-for-libcap/releasenotesfor228pending
I have a fix for libcap. I'll push it today and make a 2.32 release.
Fixed in 2.32. Please re-open if you still have issues: https://sites.google.com/site/fullycapable/release-notes-for-libcap https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=c75e832067cc14bc1d5ecb2cb21fdfe47ab5d9e5
Thanks! The test on local build looks good, so far. I pushed the package update to openSUSE Factory, and the further build test will be performed there. I'll let you know if there is still something broken.