Bug 461486 - mishandling of 'security.selinux' (other) extended attributes?
mishandling of 'security.selinux' (other) extended attributes?
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: rsync (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Simo Sorce
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-08 10:22 EDT by Tom London
Modified: 2009-01-19 21:15 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-08 10:53:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom London 2008-09-08 10:22:01 EDT
Description of problem:
I 'backup' my rawhide system (Thinkpad X60) by running:

rsync --archive --recursive --acls --xattrs --delete --exclude='/selinux' --exclude='/lost+found/*' --exclude='/dev/*' --exclude='/media/*' --exclude='/proc/*' --exclude='/sys/*' --exclude='*/.gvfs' --exclude='/mnt/disk*/*' --stats / /media/Backup1

'/media/Backup1' is a ext4dev file system on a USB hard drive that is mounted at the time.

When I run this, I have 2 ntfs-3g partitions (/mnt/windows and /mnt/music) mounted (no USB drive connected now...):

[root@tlondon ~]# mount
/dev/sda6 on / type ext3 (rw)
/proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda3 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
tmpfs on /tmp type tmpfs (rw,noexec,nosuid)
/dev/sda1 on /mnt/windows type fuseblk (rw,allow_other,blksize=4096)
/dev/sda2 on /mnt/music type fuseblk (rw,allow_other,blksize=4096)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
gvfs-fuse-daemon on /home/tbl/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=tbl)
[root@tlondon ~]# 

When running the 'rsync' command, I get large numbers of console messages similar to:

rsync: rsync_xal_clear:
lremovexattr("mnt/windows/WINDOWS/twain_32/wiatwain.ds","security.selinux")
failed: Permission denied (13)
rsync: rsync_xal_clear:
lremovexattr("mnt/windows/temp","security.selinux") failed: Permission
denied (13)
rsync: rsync_xal_clear:
lremovexattr("mnt/windows/temp/setup.log","security.selinux") failed:
Permission denied (13)

Appears that I am getting one of these messages for most (every?) file in the mounted ntfs-3g partitions.

All the files in /mnt/windows and /mnt/music have type: fusefs_t.  After
rsych'ed, the type of each file on the ext4 fs is file_t.

Running 'getfatttr -d' on the source files produces, for example (checking /mnt/windows/temp)/*:
[root@localhost temp]# getfattr -d *
getfattr: setup.log: Operation not supported
[root@localhost temp]#

On the destination fs, result is
[root@localhost temp]# getfattr -d *
[root@localhost temp]#

The upstream source for rsync-3.0.3 shows this in xattr.c:
<<<<SNIP>>>>>
static int rsync_xal_set(const char *fname, item_list *xalp,
                        const char *fnamecmp, stat_x *sxp)
{
<<<<<SNIP>>>>>
       /* Remove any extraneous names. */
       for (name = namebuf; list_len > 0; name += name_len) {
               name_len = strlen(name) + 1;
               list_len -= name_len;

#ifdef HAVE_LINUX_XATTRS
               /* We always ignore the system namespace, and non-root
                * ignores everything but the user namespace. */
               if (am_root ? HAS_PREFIX(name, SYSTEM_PREFIX)
                           : !HAS_PREFIX(name, USER_PREFIX))
                       continue;
#endif

I think this is code that attempts to synchronize the attributes on destination to match to attributes on the source by removing "extra" attributes.

I think this says: if running as root, don't remove attributes in the system namespace (but remove everything else); if running as non-root, remove all attributes but those in the user namespace.

If so, when running as root, the code will attempt to remove attributes from the security namespace (e.g., 'security.selinux').

In my case, I'm rsync-ing to an ext4 fs that supports SELinux labels/etc., but copying from an NTFS-3g fs (mounted as /mnt/XXXXX) that shows fusefs_t as labels.  "getfattr" on files in these mounted filesystems fail:

[root@tlondon ~]# getfattr /mnt/music
getfattr: /mnt/music: Operation not supported
[root@tlondon ~]#

My (first?) guess is that rsync is trying to remove the security attributes from target files to match the source file attributes (none).

I'm not sure the approach is (completely) correct.  Should rsync try to remove the security (e.g., selinux) attributes from the target?

If this is correct (and desired) it would be straightforward to patch the above code to 'continue' on both system and security attributes.  Something like:

--- xattrs.c.orig	2008-09-06 11:09:08.000000000 -0700
+++ xattrs.c	2008-09-06 11:12:50.000000000 -0700
@@ -818,9 +818,10 @@
 		list_len -= name_len;
 
 #ifdef HAVE_LINUX_XATTRS
-		/* We always ignore the system namespace, and non-root
-		 * ignores everything but the user namespace. */
-		if (am_root ? HAS_PREFIX(name, SYSTEM_PREFIX)
+		/* We always ignore the system and security namespaces,
+		 * and non-root ignores everything but the user namespace. */
+		if (am_root ? ( HAS_PREFIX(name, SYSTEM_PREFIX)
+				|| HAS_PREFIX(name, SECURITY_PREFIX) )
 			    : !HAS_PREFIX(name, USER_PREFIX))
 			continue;
 #endif

But is this the right way to handle attributes in the security
namespace?  What about "Trusted extended attributes"?

If the above is "the right way", I can create a working patch and test.

Version-Release number of selected component (if applicable):
rsync-3.0.3-0.fc10.i386

How reproducible:
Everytime

Steps to Reproduce:
1. Described above
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Simo Sorce 2008-09-08 10:53:48 EDT
(In reply to comment #0)
[..]
> When running the 'rsync' command, I get large numbers of console messages
> similar to:
> 
> rsync: rsync_xal_clear:
> lremovexattr("mnt/windows/WINDOWS/twain_32/wiatwain.ds","security.selinux")
> failed: Permission denied (13)
> rsync: rsync_xal_clear:
> lremovexattr("mnt/windows/temp","security.selinux") failed: Permission
> denied (13)
> rsync: rsync_xal_clear:
> lremovexattr("mnt/windows/temp/setup.log","security.selinux") failed:
> Permission denied (13)

It seem that the target filesystem (ext4) has a security.selinux attribute for the copy it holds. This attribute is probably not present in the original filesystem (is ntfs-3g capable of handling Extended Attributes ?).
Because of this difference, rsync tries to remove the different xattr in the destination file to make it identical to the origin.
It seem rsync has no privileges to manipulate the security. namespace on the target filesystem, therefore it fails to remove it.

[..]
> Running 'getfatttr -d' on the source files produces, for example (checking
> /mnt/windows/temp)/*:
> [root@localhost temp]# getfattr -d *
> getfattr: setup.log: Operation not supported
> [root@localhost temp]#

Ok your fuse-mounted filesystem is not capbale of handling extended attributes.

[..]
> #ifdef HAVE_LINUX_XATTRS
>                /* We always ignore the system namespace, and non-root
>                 * ignores everything but the user namespace. */
>                if (am_root ? HAS_PREFIX(name, SYSTEM_PREFIX)
>                            : !HAS_PREFIX(name, USER_PREFIX))
>                        continue;
> #endif
> 
> I think this is code that attempts to synchronize the attributes on destination
> to match to attributes on the source by removing "extra" attributes.

Exactly.
 
> I think this says: if running as root, don't remove attributes in the system
> namespace (but remove everything else); if running as non-root, remove all
> attributes but those in the user namespace.

No, it says:
if root ignore the system. namespace, synchronize everything else.
if user synchronize only the user. namespace, ignore everything else.

> If so, when running as root, the code will attempt to remove attributes from
> the security namespace (e.g., 'security.selinux').

The reason it tries to remove attributes from security. is because they do not exist in the source filesystem.

> In my case, I'm rsync-ing to an ext4 fs that supports SELinux labels/etc., but
> copying from an NTFS-3g fs (mounted as /mnt/XXXXX) that shows fusefs_t as
> labels.  "getfattr" on files in these mounted filesystems fail:

Yes the fusefs_t is a faked up label.

> [root@tlondon ~]# getfattr /mnt/music
> getfattr: /mnt/music: Operation not supported
> [root@tlondon ~]#
> 
> My (first?) guess is that rsync is trying to remove the security attributes
> from target files to match the source file attributes (none).

Correct

> I'm not sure the approach is (completely) correct.  Should rsync try to remove
> the security (e.g., selinux) attributes from the target?

you asked (--xattrs) rsync to synchronize extended attributes, it is just doing what you asked it to do.

> If this is correct (and desired) it would be straightforward to patch the above
> code to 'continue' on both system and security attributes.  Something like:
> 
> --- xattrs.c.orig 2008-09-06 11:09:08.000000000 -0700
> +++ xattrs.c 2008-09-06 11:12:50.000000000 -0700
> @@ -818,9 +818,10 @@
>    list_len -= name_len;
> 
>  #ifdef HAVE_LINUX_XATTRS
> -  /* We always ignore the system namespace, and non-root
> -   * ignores everything but the user namespace. */
> -  if (am_root ? HAS_PREFIX(name, SYSTEM_PREFIX)
> +  /* We always ignore the system and security namespaces,
> +   * and non-root ignores everything but the user namespace. */
> +  if (am_root ? ( HAS_PREFIX(name, SYSTEM_PREFIX)
> +    || HAS_PREFIX(name, SECURITY_PREFIX) )
>         : !HAS_PREFIX(name, USER_PREFIX))
>     continue;
>  #endif

This would be completely wrong.

> But is this the right way to handle attributes in the security
> namespace?  What about "Trusted extended attributes"?

No it is not, the current code is correct.

> If the above is "the right way", I can create a working patch and test.

No it is not, the 'right' way is to not use --xattrs if your source filesystem does not implement them, as there is no xattr to synchronize anyway.

In short, this is a "configuration" problem, not a bug, the code operates as expectd, therefore I am closing this one.
Comment 2 Tom London 2008-09-08 12:05:47 EDT
OK.  Thanks for the comments.

Per above, I should "--exclude=/mnt/windows/*" and "--exclude=/mnt/music/*" and sync them with a separate "rsync" without the "-xattr" option.  

Right?
Comment 3 Szabolcs Szakacsits 2009-01-19 21:15:50 EST
NTFS-3G is capable of handling extended attributes if the streams_interface=xattr mount option is specified. However the "security." namespace is not permitted at the moment.

In the near future full, unconditional EA support will be released (no mount option will be needed).

Note You need to log in before you can comment on or make changes to this bug.