On 05/02/2014 11:19 PM, Pádraig Brady wrote: > On 12/13/2013 04:43 PM, A. Wan wrote: >> I wonder if this is a bug or I just did it the wrong way. I can't seem to >> copy extended attributes of symbolic links. Example is to populate the >> upperdir of an overlayfs in Linux. >> >> coreutils 8.21 >> libattr 2.4.47 >> >> I can only use mv to preserve extended attributes of symbolic links, >> and only when the destination is in the same filesystem. (It looks like >> mv summons copy when destination is in a different filesystem) >> >> Steps to reproduce: (The same happens in either ext2 or tmpfs) >> >> --- cut here --- >> touch a >> ln -sv '(overlay-whiteout)' b >> >> | ‘b’ -> ‘(overlay-whiteout)’ >> >> setfattr -hn trusted.overlay.whiteout -v y a >> setfattr -hn trusted.overlay.whiteout -v y b >> getfattr -hn trusted.overlay.whiteout a >> >> | # file: a >> | trusted.overlay.whiteout="y" >> >> getfattr -hn trusted.overlay.whiteout b >> >> | # file: b >> | trusted.overlay.whiteout="y" >> >> cp -vaP a c >> >> | ‘a’ -> ‘c’ >> >> cp -vaP b d >> >> | ‘b’ -> ‘d’ >> >> getfattr -hn trusted.overlay.whiteout c >> >> | # file: c >> | trusted.overlay.whiteout="y" >> >> getfattr -hn trusted.overlay.whiteout d >> >> | d: trusted.overlay.whiteout: No such attribute >> >> --- cut here --- > > > Thanks for the detailed reproduction. > The combinations are tricky here. > > First, some general notes I've noticed on Linux. > > - xattrs in the user. namespace are not allowed on symlinks, only on regular > files and dirs. > - xattrs in the trusted. namespace are only listed for root user > > Therefore this would only be significant for attributes in non user. > namespace, > and only for the root user with the trusted. namespace at least. > > So should cp/mv be copying these xattrs across file system boundaries? > Since they're already preserved with a rename, then it would be more > consistent to copy them. > Currently we don't attempt this, but the patch would be fairly trivial, > since attr_copy_file() doesn't reference symlinks (since 2004). > > Note security context and capabilities etc. are also stored in xattrs, > but we already filter selinux context at least in our attr_copy_file() > wrapper, > so that `mv -Z` for example won't be impacted. Also in the attacjed patch > I was careful to maintain the order of set_owner() and copy_attr() > so that capabilities weren't inadvertently cleared. > > I'll add a root only test later along the lines of the above.
and the test... diff --git a/tests/cp/cp-mv-enotsup-xattr.sh b/tests/cp/cp-mv-enotsup-xattr.sh index f8cdd45..d711683 100755 --- a/tests/cp/cp-mv-enotsup-xattr.sh +++ b/tests/cp/cp-mv-enotsup-xattr.sh @@ -106,4 +106,24 @@ mv xattr/a noxattr/ 2>err || fail=1 test -s noxattr/a || fail=1 # destination file must not be empty test -s err && fail=1 # there must be no stderr output +# This should pass and copy xattrs of the symlink +# since they're not in the 'user.' namespace. +# Up to and including coreutils-8.22 xattrs of symlinks +# were not copied across file systems. +ln -s 'foo' xattr/symlink || framework_failure_ +# Note 'user.' namespace is only supported on regular files/dirs +# so use the 'trusted.' namespace here +txattr='trusted.overlay.whiteout' +if setfattr -hn trusted.overlay.whiteout -v y xattr/symlink; then + # Note only root can read the 'trusted.' namespace + if getfattr -h -m- -d xattr/symlink | grep -F "$txattr"; then + mv xattr/symlink noxattr/ || fail=1 + getfattr -h -m- -d noxattr/symlink | grep -F "$txattr" || fail=1 + else + echo "failed to get 'trusted.' xattr of symlink" >&2 + fi +else + echo "failed to set 'trusted.' xattr of symlink" >&2 +fi + Exit $fail
