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 :|