[Bug 8201] rsync 3.0.8 destroys SELinux security context of symbolic links

samba-bugs at samba.org samba-bugs at samba.org
Tue Jun 14 09:40:49 MDT 2011


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.


More information about the rsync mailing list