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
confirmed http://lists.samba.org/archive/rsync/2011-April/026263.html
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.
Wayne, your change regressed bug 7109. Linux needs NO_SYMLINK_XATTRS only for the "user" namespace.
(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.
(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.
(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?
(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.
A fix for this will be in 3.0.9 (coming soon).
Wayne, I wouldn't close this until you have a fix that doesn't regress fake-super for symlinks.
There is no regression. You're thinking of 3.1.0.
Verified with rsync a59a7b242393699fedeb4f66911e3fc9b4fadd73. Thanks!
(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.