Bug 8201 - rsync should copy non-user xattrs of symlinks on Linux
rsync should copy non-user xattrs of symlinks on Linux
Status: RESOLVED FIXED
Product: rsync
Classification: Unclassified
Component: core
3.0.9
All Linux
: P5 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-01 15:53 UTC by martin.wilck
Modified: 2011-06-20 21:10 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description martin.wilck 2011-06-01 15:53:48 UTC
Description of problem:
P2V conversion of a F14 installation: used rsync -aHAXx to duplicate file
systems from physical to virtual host.

Version-Release number of selected component (if applicable):
rsync-3.0.8-1.fc14.x86_64

How reproducible:
always

Steps to Reproduce:
Physical-2-Virtual conversion of a F14 installation: used rsync -aHAXx to
duplicate file systems from physical to virtual host.

Actual results:
on source:
lrwxrwxrwx. root root system_u:object_r:lib_t:s0       /lib64/libc.so.6 ->
libc-2.13.so
on target:
lrwxrwxrwx. root root unconfined_u:object_r:file_t:s0  /lib64/libc.so.6 ->
libc-2.13.so

These changed security contexts for symlinks cause the boot of the newly
created VM to fail unless boot parameter selinux=0 is used.

Expected results:
Newly created VM bots nicely

Additional info:
Reproducer:

mkdir SRC
touch SRC/file
ln -s file SRC/link
chcon -h system_u:object_r:lib_t:s0 SRC/*
ls -Z SRC
-rw-r--r--. root root system_u:object_r:lib_t:s0       file
lrwxrwxrwx. root root system_u:object_r:lib_t:s0       link -> file

mkdir TGT
rsync -aHAXx SRC/ TGT
ls -Z TGT
-rw-r--r--. root root system_u:object_r:lib_t:s0       file
lrwxrwxrwx. root root unconfined_u:object_r:user_tmp_t:s0 link -> file

This seems to have been a deliberate change in rsync:

commit 9d6fe1a6f0233c7567dfb114835751aff85a578b
Author: Wayne Davison <wayned@samba.org>
Date:   Mon Jan 3 11:07:47 2011 -0800

    Avoid reading ACL/xattr info on filetypes not being copied.
    Make Linux avoid xattr access on symlinks.
    Make OS X avoid xattr access on device/special files.
    Fixes bug 5458.

https://bugzilla.samba.org/show_bug.cgi?id=5458
https://bugzilla.samba.org/show_bug.cgi?id=7109

The reason given for this change was a reference to the attr(5) man page:   
"For this reason, extended user attributes are only allowed for regular files
and directories, ...". 

However, that section applies to *user* attributes only.
The changes made so rsync affect all attribute name spaces, including security attributes, and apply even if rsync is run by the super user. This is quite obviously wrong.

https://bugzilla.redhat.com/show_bug.cgi?id=709779
Comment 1 Frederick Grose 2011-06-01 17:53:01 UTC
confirmed
http://lists.samba.org/archive/rsync/2011-April/026263.html
Comment 2 Wayne Davison 2011-06-04 15:39:30 UTC
Comment out NO_SYMLINK_XATTRS in config.h and that rsync should copy the xattrs just fine.  I'll get a fix checked in for this.
Comment 3 Matt McCutchen 2011-06-04 20:45:10 UTC
Wayne, your change regressed bug 7109.  Linux needs NO_SYMLINK_XATTRS only for the "user" namespace.
Comment 4 martin.wilck 2011-06-06 09:49:00 UTC
(In reply to comment #3)
> Wayne, your change regressed bug 7109.  Linux needs NO_SYMLINK_XATTRS only for
> the "user" namespace.

IMHO NO_SYMLINK_XATTRS doesn't have the right semantics. Under Linux, trying to read or set a "user" attribute on a symlink will raise EPERM. The Right Thing to do for rsync would be to ignore this specific type of error. That's not what NO_SYMLINK_XATTRS does, AFAICS.
Comment 5 Matt McCutchen 2011-06-08 00:01:41 UTC
(In reply to comment #4)
> IMHO NO_SYMLINK_XATTRS doesn't have the right semantics.

I assume you mean "a new NO_SYMLINK_XATTRS-like switch that applies only to the user namespace" like I did.

> Under Linux, trying to
> read

No, reading is fine; there just will never be any user xattrs.

> or set a "user" attribute on a symlink will raise EPERM. The Right Thing
> to do for rsync would be to ignore this specific type of error.

For setting, I disagree.  The data loss compared to the source constitutes an error.

> That's not what
> NO_SYMLINK_XATTRS does, AFAICS.

NO_SYMLINK_XATTRS causes symlink xattr reads and writes to return the empty set and ENOTSUP, respectively, without calling the OS.  On Linux, this is just an optimization unless you care about the difference in the error code.  It's conceivable that another OS might return an error on reads, in which case rsync would not want to pass that error along.

The more significant effect of NO_SYMLINK_XATTRS is to tell the fake-super mode to store symlinks as regular files so it can attach the fake-super xattr.  If rsync waited to get EPERM on the symlink, it would have to go back and replace the symlink with a regular file.
Comment 6 martin.wilck 2011-06-14 15:40:48 UTC
(In reply to comment #5)
>> Under Linux, trying to
>> read
> 
> No, reading is fine; there just will never be any user xattrs.

I repeat - trying to read a user attr of a symlink raises EPERM. This is on Fedora 15, 2.6.38.6-27.fc15:

[root@cooper SRC]# ls -lZ
-rw-r--r--. root root system_u:object_r:lib_t:s0       file
lrwxrwxrwx. root root system_u:object_r:lib_t:s0       link -> file

[root@cooper SRC]# getfattr -h -n user.mime_type link 
link: user.mime_type: Operation not permitted

[root@cooper SRC]# strace getfattr -h -n user.mime_type link
...
lstat("link", {st_mode=S_IFLNK|0777, st_size=4, ...}) = 0
lgetxattr("link", "user.mime_type", 0x0, 0) = -1 EPERM (Operation not permitted)
...

> NO_SYMLINK_XATTRS causes symlink xattr reads and writes to return the empty set
> and ENOTSUP, respectively, without calling the OS.  On Linux, this is just an
> optimization unless you care about the difference in the error code.  It's
> conceivable that another OS might return an error on reads, in which case rsync
> would not want to pass that error along.

I can't follow you. Not even trying to call the OS isn't "just an optimization", it is plain wrong for all except "user" attributes.

> The more significant effect of NO_SYMLINK_XATTRS is to tell the fake-super mode
> to store symlinks as regular files so it can attach the fake-super xattr.  If
> rsync waited to get EPERM on the symlink, it would have to go back and replace
> the symlink with a regular file.

Actually, I don't care if rsync just traps EPERM or checks the attribute namespace before trying to set it. That's mostly a matter of programming style.

How do we proceed now?
Comment 7 Matt McCutchen 2011-06-15 00:17:03 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > No, reading is fine; there just will never be any user xattrs.
> 
> I repeat - trying to read a user attr of a symlink raises EPERM.

Oh.  Since rsync only reads the xattrs that exist, it never sees that case.

> I can't follow you. Not even trying to call the OS isn't "just an
> optimization", it is plain wrong for all except "user" attributes.

I was mixed up.  It is the hypothetical NO_SYMLINK_USER_XATTRS that would be just an optimization on Linux.
Comment 8 Wayne Davison 2011-06-18 17:33:28 UTC
A fix for this will be in 3.0.9 (coming soon).
Comment 9 Matt McCutchen 2011-06-18 17:48:18 UTC
Wayne, I wouldn't close this until you have a fix that doesn't regress fake-super for symlinks.
Comment 10 Wayne Davison 2011-06-18 20:06:27 UTC
There is no regression.  You're thinking of 3.1.0.
Comment 11 martin.wilck 2011-06-20 08:35:35 UTC
Verified with rsync a59a7b242393699fedeb4f66911e3fc9b4fadd73. Thanks!
Comment 12 Matt McCutchen 2011-06-20 21:10:57 UTC
(In reply to comment #10)
> There is no regression.  You're thinking of 3.1.0.

You are right.  I.e., 3.1.x has the complete solution, and for 3.0.x it is OK to just turn off NO_SYMLINK_XATTRS because 3.0.x never had the symlink-to-regular-file feature.