On 29/10/10 04:15, Jason L Tibbitts III wrote: >>>>>> "JN" == Joe Nall<joe@xxxxxxxx> 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
