Bug 6546 - Rsync incurs errors trying to remove "security.selinux" xattr
Summary: Rsync incurs errors trying to remove "security.selinux" xattr
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.6
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2009-07-09 20:18 UTC by Dave Yost
Modified: 2020-07-08 03:03 UTC (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Dave Yost 2009-07-09 20:18:27 UTC
See https://bugzilla.redhat.com/show_bug.cgi?id=450360

Z% rsync -aHSAXR backup /
... [lots of errors like the ones below]
rsync: rsync_xal_clear: lremovexattr("backup/vaults/s4/data/2009-07-04_05-09/var/log/.secure.P1N7VQ","security.selinux") failed: Permission denied (13)
rsync: rsync_xal_clear: lremovexattr("backup/vaults/s4/data/2009-07-04_05-09/var/log/audit/.audit.log.GHzRLK","security.selinux") failed: Permission denied (13)
rsync: rsync_xal_clear: lremovexattr("backup/vaults/s4/data/2009-07-04_05-09/var/run/.utmp.wjUr8E","security.selinux") failed: Permission denied (13)
rsync: rsync_xal_clear: lremovexattr("backup/vaults/s4/data/2009-07-04_05-09/var/run/mysqld/.mysqld.pid.DAHgkC","security.selinux") failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1039) [sender=3.0.6]

Is rsync trying to tell me by that last line about main.c that there is a bug?
Comment 1 Wayne Davison 2009-09-05 11:52:01 UTC
The last line is telling you that there were prior errors in either transferring files or file permissions/attributes.  In this case, all the xattr removal failures.
Comment 2 Matt McCutchen 2009-09-05 14:38:27 UTC
Ignore the remark in comment #0.  The issue is that SELinux won't allow any process to remove the "security.selinux" attribute, so perhaps rsync should not try.  OTOH, if SELinux is disabled, removing the attribute might be a useful thing to do.  One option would be to block this on bug 4573 and require the user to specify --xattr-filter='P security.selinux' when desired.
Comment 3 Dave Yost 2009-09-05 15:36:44 UTC
Ordinary warnings and data dependent errors are not bugs and shouldn't look like bugs. Source code file name and line number makes it look like a bug and should not be shown except for a bug.
Comment 4 tmhikaru 2016-08-10 01:58:41 UTC
I have been having problems with this bug on 3.1.1 and 3.1.2. To test if the latest version's xattr fixes would affect it, I also built the git version of 3.1.3dev which is git commit 31e93c322865acea7533176c2278b259890662fc but it has not helped. What I am seeing:

rsync: rsync_xal_set: lremovexattr(""/media/backup/main/2016-08-09/sys"","security.selinux") failed: Permission denied (13)

rsync does not error out, and completes without an errno but prints this message at the end:
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1186) [sender=3.1.3dev]

Here is the directory in question on my various backups as well as the actual directory it is attempting to backup:

tm@roll:~/src/rsync$ ls -laZd /media/backup/main/2016-*/sys /sys
dr-xr-xr-x.  2 root root unconfined_u:object_r:default_t:s0   4096 Jul 21 20:09 /media/backup/main/2016-07-22/sys
dr-xr-xr-x.  2 root root unconfined_u:object_r:unlabeled_t:s0 4096 Jul 26 12:24 /media/backup/main/2016-07-26/sys
dr-xr-xr-x.  2 root root unconfined_u:object_r:unlabeled_t:s0 4096 Jul 29 22:00 /media/backup/main/2016-07-30/sys
dr-xr-xr-x.  2 root root unconfined_u:object_r:unlabeled_t:s0 4096 Aug  3 12:41 /media/backup/main/2016-08-03/sys
dr-xr-xr-x.  2 root root unconfined_u:object_r:unlabeled_t:s0 4096 Aug  6 13:34 /media/backup/main/2016-08-06/sys
dr-xr-xr-x.  2 root root unconfined_u:object_r:unlabeled_t:s0 4096 Aug  9 14:25 /media/backup/main/2016-08-09/sys
dr-xr-xr-x. 13 root root system_u:object_r:sysfs_t:s0            0 Aug  9 14:25 /sys

I imagine the problem may be related to the fact I am using unusual features such as --link-dest, so I will do some further testing to determine what actually is making rsync goof up with this.
Comment 5 tmhikaru 2016-08-10 03:14:11 UTC
After some further testing I have some fairly odd results, possibly related. Using --link-dest to point to an already existing backup set, or the same empty directory that we are backing up to causes the bug to appear. If I use --link-dest while pointing it at an empty directory and backing up to an empty directory, it does not happen.

Using rsync without it with the destination being an empty directory causes no errors.

Using rsync without it with the destination already having copies of the files causes the error to occur.

So it appears that if rsync notices that the /sys directory exists on the destination, it does the wrong thing.

here's two examples of how I'm invoking it:
without --link-dest:
/home/tm/src/rsync/rsync --stats -vaxAXRHS --preallocate --progress --delete --delete-excluded / /media/backup/test/1 --exclude-from /root/backupexcludes.txt

with --link-dest: (2 is empty and holds nothing. 1 was rm'd before the copy began.)
/home/tm/src/rsync/rsync --stats -vaxAXRHS --preallocate --progress --delete --delete-excluded --link-dest=/media/backup/test/2 / /media/backup/test/1 --exclude-from /root/backupexcludes.txt

Anything else I can provide to help identify this?
Comment 6 EML 2016-08-29 14:38:01 UTC
I'm seeing this on a clean Centos 7.2.1511 install, rsync 3.0.9.

selinux is disabled on the src, and enabled on the dst, but in permissive mode, so I'm not expecting errors.

'ausearch -m avc -ts recent' shows nothing, and there's nothing recent in /var/log/audit/audit.log. So selinux isn't reporting an issue, but rsync is.

My specific errors are

# rsync -avXz -e 'ssh -p 1234' remote-sys:/var/www/ www
...lots of:
rsync: rsync_xal_set: lremovexattr(""/var/www/."","security.selinux") failed: Permission denied (13)

Note that this only happens when I run as root, and when backing up something with extended attributes. I'm not seeing any of the --link-dest/whatver complciations from comment #5 - this is a completely standard backup of a remote system with xattrs.

Any workaround suggestions? It's difficult to run as an ordinary user because I can't run as the remote user (apache).
Comment 7 Wayne Davison 2020-07-08 03:03:23 UTC
You can now specify xattr filter rules, such as -f='-x! user.*' to make a root copy ignore everything but user.* xattrs, or the combo of -f='-x system.*' -f='-x security.*' to ignore  the system & security prefixes.