The Samba-Bugzilla – Bug 13241
A problem with test for xattrs transfer
Last modified: 2018-03-01 12:04:38 UTC
when running tests for rsync on Fedora, it fails on the xattrs.test and xattrs-hlink.test. It always fails on the line
rsync -aiX --fake-super --link-dest=../chk . ../to
with this result:
--- omitted ---
user.dir1="need to test directory xattrs too"
user.dir3="this is one last one for the moment"
--- omitted ---
for basically every file. This only happens when the --fake-super option is on. For instance line
rsync-3.1.2/rsync -aiX -H --super --link-dest=../chk . ../to
is not affected.
Looking at the xls() method in the test, it uses 'getfattr -d'. The original files will never show the user.rsync.security.selinux="unconfined_u:object_r:user_home_t:s0" with this command. This attribute has to be specifically asked for with 'getfattr -n security.selinux'.
Looking into the code the function sys_lgetxattr is used to get extended attributes and it asks specifically for the security.selinux attribute. And this attribute gets transferred to the destination file and is visible with 'getfattr -d'.
> mkdir dir_a dir_b
> echo "Hello world" > dir_a/foo.txt
> getfattr -d dir_a/foo.txt
> getfattr -n security.selinux dir_a/foo.txt
# file: dir_a/foo.txt
> rsync -aiX --fake-super dir_a/ dir_b/
> getfattr -d dir_b/foo.txt
# file: dir_b/foo.txt
As you can see rsync transfers this attribute and it is visible after issuing 'getfattr -d'. I'm not sure if this should happen but either the xattrs.txt file used for the diff in the test should be edited or there is something wrong with the --fake-super option combined with -X.
Thanks for any help on this.
When I run "make check" (version 3.1.3) the xattrs test reports
Running .../rsync/rsync -aiX -f-x_system.* -f-x_security.* --fake-super --link-dest=../chk . ../to
which appears to be specifically excluding copying any system.* or security.* xattrs in --fake-super mode (and the same in --super mode, for that matter), thus avoiding spurious diffs for additional xattrs that may be present on certain systems.
So it looks like this problem is already fixed by
Author: Wayne Davison <firstname.lastname@example.org>
Date: Sun Jan 22 16:01:45 2017 -0800
Thanks for the answer Dave, I filed this bug a few days before the 3.1.3 version came out. I was trying the make check with 3.1.2 release and there it was failing. With the new version this test passes without problems.