bug#16131: copy extended attributes of a symbolic link

[Pádraig Brady]

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.

thanks,
Pádraig.

preserve-symlink-xattrs.patch
Description: Text Data