bug#16131: copy extended attributes of a symbolic link

[Pádraig Brady]

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