Can you check /proc/self/status to see the capabilities mask you have.

[root@fedora2 ~]# cat /proc/self/status | grep ^Cap CapInh: 0000000000000000 CapPrm: 0000001db5feffff CapEff: 0000001db5feffff CapBnd: 0000001db5feffff [root@fedora2 ~]# capsh --print Current: =ep cap_sys_module,cap_sys_time,cap_mknod,cap_audit_control,cap_mac_admin-ep Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_tty_config,cap_lease,cap_audit_write,cap_setfcap,cap_mac_override,cap_syslog,35,36 Securebits: 00/0x0/1'b0 secure-noroot: no (unlocked) secure-no-suid-fixup: no (unlocked) secure-keep-caps: no (unlocked) uid=0(root) gid=0(root) groups=

Also what kernel version are you using ? I'd pretty much be expecting this to just work already.

[root@nuhost105 ~]# uname -r 3.13.2-3.el6.x86_64 /stephan -- Software is like sex, it's better when it's free!

On Wed, Feb 26, 2014 at 11:38:08AM +0100, Stephan Sachse wrote:

trusted.* xattrs are only for CAP_SYS_ADMIN

[host] # setfattr -n trusted.me.md5 -v d41d8cd98f00b204e9800998ecf8427e xattr-test [host] # getfattr -m - -d xattr-test # file: xattr-test trusted.me.md5="d41d8cd98f00b204e9800998ecf8427e"

[lxc] # getfattr -n trusted.me.md5 xattr-test xattr-test: trusted.me.md5: No such attribute [lxc] # strace -e trace=getxattr getfattr -n trusted.me.md5 xattr-test getxattr("xattr-test", "trusted.me.md5", 0x0, 0) = -1 ENODATA (No data available) xattr-test: trusted.me.md5: No such attribute +++ exited with 1 +++

maybe ENODATA is from here http://lxr.free-electrons.com/source/fs/xattr.c#L56

so the capable(CAP_SYS_ADMIN) check fails. and if this check fails the check in cap_inode_setxattr() http://lxr.free-electrons.com/source/security/commoncap.c#L620 will also fail. but I don't know why. CAP_SYS_ADMIN is there

The capable() function only suceeds in the primary host namespace. The kernel uses ns_capable() in cases where container namespaces are allowed to use capabilities. So this indicates that the kernel guys didn't believe it to be safe to allow use of the 'trusted' xattr namespace in containers. That said, I didn't think the 'trusted.' prefix was needed for package installation. It thought it used the 'security.' xattr prefix for file ACLs. 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 :|

for me there is no valid reason why a container is not allowed to set file capabilities. and here is the patch (send to Eric W. Biederman <ebiederm@xmission.com>) works for me -- Software is like sex, it's better when it's free!

On Wed, Feb 26, 2014 at 08:54:02AM -0600, Serge Hallyn wrote:

Quoting Stephan Sachse (ste.sachse@gmail.com):

...

for me there is no valid reason why a container is not allowed to set file capabilities.

(For the sake of the libvir-list, I replied to this on the lxc-devel@ list with a proposal that should work; but this particular patch is not safe, as nothing would stop an unprivileged user from mapping 0 to his uid in a new namespace, adding CAP_SYS_ADMIN, getting back to the init namespace, and running it with privilege. Adding a new capability format which adds the kuid_t of the user_ns root would solve this. Thanks Stephan for pushing on this.)

Thanks, I thought there would be some good reason for this restriction. 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 :|