On 29/10/10 04:15, Jason L Tibbitts III wrote:
"JN" == Joe Nalljoe@nall.com writes:
JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden "capabilities" are present on a binary? 'ls' doesn't mention anything.
JN> getcap
Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages.
I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it.
I've just come across another issue with this. I use the "tmpfs" plugin with mock usually, and it appears that tmpfs doesn't support the necessary file capabilities, as I get these errors when setting up the buildroot:
DEBUG util.py:267: Error unpacking rpm package iputils-20101006-2.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported DEBUG util.py:267: Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported
If I disable the tmpfs plugin, so mock uses the ext3 filesystem I have on /var/lib/mock, the build succeeds. So at least I have a workaround but I'd like to have tmpfs working as it *really* improves performance.
Paul.