rsync - Jun 2011 - [Bug 8201] New: rsync 3.0.8 destroys SELinux security context of symbolic links

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

           Summary: rsync 3.0.8 destroys SELinux security context of
                    symbolic links
           Product: rsync
           Version: 3.0.8
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: core
        AssignedTo: wayned at samba.org
        ReportedBy: martin.wilck at ts.fujitsu.com
         QAContact: rsync-qa at samba.org


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 at 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

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

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

Frederick Grose <fgrose at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fgrose at gmail.com

--- Comment #1 from Frederick Grose <fgrose at gmail.com> 2011-06-01
17:53:01 UTC ---
confirmed
http://lists.samba.org/archive/rsync/2011-April/026263.html

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

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

Wayne Davison <wayned at samba.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #2 from Wayne Davison <wayned at samba.org> 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.

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

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

--- Comment #3 from Matt McCutchen <matt at mattmccutchen.net> 2011-06-04
20:45:10 UTC ---
Wayne, your change regressed bug 7109.  Linux needs NO_SYMLINK_XATTRS only for
the "user" namespace.

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

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

--- Comment #4 from Martin Wilck <martin.wilck at ts.fujitsu.com>
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.

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

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

--- Comment #5 from Matt McCutchen <matt at mattmccutchen.net> 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.

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

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

--- Comment #6 from Martin Wilck <martin.wilck at ts.fujitsu.com>
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 at 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 at cooper SRC]# getfattr -h -n user.mime_type link 
link: user.mime_type: Operation not permitted

[root at 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?

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

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

--- Comment #7 from Matt McCutchen <matt at mattmccutchen.net> 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.

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

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

Wayne Davison <wayned at samba.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
            Version|3.0.8                       |3.0.9
         Resolution|                            |FIXED

--- Comment #8 from Wayne Davison <wayned at samba.org> 2011-06-18
17:33:28 UTC ---
A fix for this will be in 3.0.9 (coming soon).

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

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

Matt McCutchen <matt at mattmccutchen.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #9 from Matt McCutchen <matt at mattmccutchen.net> 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.

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

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

Wayne Davison <wayned at samba.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #10 from Wayne Davison <wayned at samba.org> 2011-06-18
20:06:27 UTC ---
There is no regression.  You're thinking of 3.1.0.

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

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

--- Comment #11 from Martin Wilck <martin.wilck at ts.fujitsu.com>
2011-06-20 08:35:35 UTC ---
Verified with rsync a59a7b242393699fedeb4f66911e3fc9b4fadd73. Thanks!

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

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

--- Comment #12 from Matt McCutchen <matt at mattmccutchen.net> 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.

-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.