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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list