rsync, xattrs, ntfs-3g and "selinux.selinux"

[Tom London]

Running rawhide.

I use "rsync" to backup my system to a USB hard drive.

I also ntfs-3g mount a WinXP partition to '/mnt/windows' on boot, and
I use the above rsync to back that up as well.

Adding '-xattrs' to the argument list for rsync seems to produce scads
of the following (I'm guessing one for each file in the ntfs-3g file
system ):

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)

Destination fs i ext4dev.

When mounted, all the files in /mnt/windows have type: fusefs_t.  When
rsych'ed, the type on the ext4 fs is file_t.

Running 'getfatttr -d' on the source files produces, for example:
[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]#

This something due to the way I mounted the ntfs-3g fs? The way I run
rsync?  Other?

thanks,
   tom
-- 
Tom London

[Murray McAllister]

Tom London wrote:
>  Running rawhide.
>  
>  I use "rsync" to backup my system to a USB hard drive.
>  
>  I also ntfs-3g mount a WinXP partition to '/mnt/windows' on boot, and
>  I use the above rsync to back that up as well.
>  
>  Adding '-xattrs' to the argument list for rsync seems to produce scads
>  of the following (I'm guessing one for each file in the ntfs-3g file
>  system ):
>  
>  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)
>  
>  Destination fs i ext4dev.
>  
>  When mounted, all the files in /mnt/windows have type: fusefs_t.  When
>  rsych'ed, the type on the ext4 fs is file_t.
>  
>  Running 'getfatttr -d' on the source files produces, for example:
>  [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]#
>  
>  This something due to the way I mounted the ntfs-3g fs? The way I run
>  rsync?  Other?
>  
>  thanks,
>     tom 
This might be off topic, but I am unable to get rsync -X to preserve the 
SELinux context: <https://bugzilla.redhat.com/show_bug.cgi?id=458014>;.

Cheers.

[Tom London]

On Sun, Aug 24, 2008 at 3:16 PM, Murray McAllister <mmcallis(a)redhat.com&gt; wrote:
>  Tom London wrote:
> >
> > Running rawhide.
> >
> > I use "rsync" to backup my system to a USB hard drive.
> >
> > I also ntfs-3g mount a WinXP partition to '/mnt/windows' on boot, and
> > I use the above rsync to back that up as well.
> >
> > Adding '-xattrs' to the argument list for rsync seems to produce scads
> > of the following (I'm guessing one for each file in the ntfs-3g file
> > system ):
> >
> > 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)
> >
> > Destination fs i ext4dev.
> >
> > When mounted, all the files in /mnt/windows have type: fusefs_t.  When
> > rsych'ed, the type on the ext4 fs is file_t.
> >
> > Running 'getfatttr -d' on the source files produces, for example:
> > [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]#
> >
> > This something due to the way I mounted the ntfs-3g fs? The way I run
> > rsync?  Other?
> >
> > thanks,
> >   tom
>
>  This might be off topic, but I am unable to get rsync -X to preserve the
>  SELinux context: <https://bugzilla.redhat.com/show_bug.cgi?id=458014>;.
>
>  Cheers.
>  
Appears that your issue is different: I'm running source and
destination on the same rawhide server.

Apparently, no problem with preserving contexts, just the above issue
with "mounted ntfs-3g" files.

tom
-- 
Tom London

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom London wrote:
>  Running rawhide.
>  
>  I use "rsync" to backup my system to a USB hard drive.
>  
>  I also ntfs-3g mount a WinXP partition to '/mnt/windows' on boot, and
>  I use the above rsync to back that up as well.
>  
>  Adding '-xattrs' to the argument list for rsync seems to produce scads
>  of the following (I'm guessing one for each file in the ntfs-3g file
>  system ):
>  
>  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)
>  
>  Destination fs i ext4dev.
>  
>  When mounted, all the files in /mnt/windows have type: fusefs_t.  When
>  rsych'ed, the type on the ext4 fs is file_t.
>  
>  Running 'getfatttr -d' on the source files produces, for example:
>  [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]#
>  
>  This something due to the way I mounted the ntfs-3g fs? The way I run
>  rsync?  Other?
>  
>  thanks,
>     tom 
Looks like an rsync bug?

James did you work on rsync?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAki+q/oACgkQrlYvE4MpobP4SwCg2z+iKYk8e7Z43WFJhCAXccOI
> IRUAoN62L3+4eDi7Kf39M8URZCDHROQS
> =Zx2l
> -----END PGP SIGNATURE-----

[James Antill]

On Wed, 2008-09-03 at 11:23 -0400, Daniel J Walsh wrote:

>  Looks like an rsync bug?
>  
>  James did you work on rsync? 
 Nope, looking at the rpm changelog shows:


* Mon Feb 19 2007 Simo Sorce <ssorce(a)redhat.com&gt; - 2.6.9-2
- fix acl/xattr bug with --delete: (bz#229145)

[...]

* Fri Jun 09 2006 Jay Fenlason <fenlason(a)redhat.com&gt; 2.6.8-3
- Add my xattrs_bug patch to fix a bug where xattrs don't get sent
correctly.
[...]

* Mon May 08 2006 Jay Fenlason <fenlason(a)redhat.com&gt; 2.6.8-2
- New upstream release
- Use the upstream xattr patch instead of mine.  This closes
  bz#190208 CVE-2006-2083 rsync buffer overflow issue

[...]

* Thu Feb 10 2005 Jay Fenlason <fenlason(a)redhat.com&gt; 2.6.3-2
- Added my -xattr patch, which is based on the -acl patch.


-- 
James Antill <jantill(a)redhat.com&gt;
Red Hat

[Tom London]

On Wed, Sep 3, 2008 at 8:55 AM, James Antill <jantill(a)redhat.com&gt; wrote:
>  On Wed, 2008-09-03 at 11:23 -0400, Daniel J Walsh wrote:
>
> > Looks like an rsync bug?
> >
> > James did you work on rsync?
>
>   Nope, looking at the rpm changelog shows:
>
>
>  * Mon Feb 19 2007 Simo Sorce <ssorce(a)redhat.com&gt; - 2.6.9-2
>  - fix acl/xattr bug with --delete: (bz#229145)
>
>  [...]
>
>  * Fri Jun 09 2006 Jay Fenlason <fenlason(a)redhat.com&gt; 2.6.8-3
>  - Add my xattrs_bug patch to fix a bug where xattrs don't get sent
>  correctly.
>  [...]
>
>  * Mon May 08 2006 Jay Fenlason <fenlason(a)redhat.com&gt; 2.6.8-2
>  - New upstream release
>  - Use the upstream xattr patch instead of mine.  This closes
>   bz#190208 CVE-2006-2083 rsync buffer overflow issue
>
>  [...]
>
>  * Thu Feb 10 2005 Jay Fenlason <fenlason(a)redhat.com&gt; 2.6.3-2
>  - Added my -xattr patch, which is based on the -acl patch.
>
>
>  --
>  James Antill <jantill(a)redhat.com&gt;
>  Red Hat
>  
I looked into this a bit.....

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 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).

Is this logic wrong?  Should rsync try to remove the security (e.g.,
selinux) attributes from the target?

It would be straightforward to patch the above code to 'continue' on
both system and security attributes.  Something like:

--- xattrs.c	2008-09-06 11:12:50.000000000 -0700
+++ xattrs.c.orig	2008-09-06 11:09:08.000000000 -0700
@@ -818,10 +818,9 @@
 		list_len -= name_len;

 #ifdef HAVE_LINUX_XATTRS
-		/* 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) )
+		/* 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

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.

If not, I could use some "enlightenment"..... ;)

tom
-- 
Tom London

[Daniel J Walsh]

Tom London wrote:
>  On Wed, Sep 3, 2008 at 8:55 AM, James Antill
> <jantill(a)redhat.com&gt; wrote:
> > On Wed, 2008-09-03 at 11:23 -0400, Daniel J Walsh wrote:
> >
> >> Looks like an rsync bug?
> >>
> >> James did you work on rsync?
> >  Nope, looking at the rpm changelog shows:
> >
> >
> > * Mon Feb 19 2007 Simo Sorce <ssorce(a)redhat.com&gt; - 2.6.9-2
> > - fix acl/xattr bug with --delete: (bz#229145)
> >
> > [...]
> >
> > * Fri Jun 09 2006 Jay Fenlason <fenlason(a)redhat.com&gt; 2.6.8-3
> > - Add my xattrs_bug patch to fix a bug where xattrs don't get sent
> > correctly.
> > [...]
> >
> > * Mon May 08 2006 Jay Fenlason <fenlason(a)redhat.com&gt; 2.6.8-2
> > - New upstream release
> > - Use the upstream xattr patch instead of mine.  This closes
> >  bz#190208 CVE-2006-2083 rsync buffer overflow issue
> >
> > [...]
> >
> > * Thu Feb 10 2005 Jay Fenlason <fenlason(a)redhat.com&gt; 2.6.3-2
> > - Added my -xattr patch, which is based on the -acl patch.
> >
> >
> > --
> > James Antill <jantill(a)redhat.com&gt;
> > Red Hat
> >
>  I looked into this a bit.....
>  
>  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 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).
>  
>  Is this logic wrong?  Should rsync try to remove the security (e.g.,
>  selinux) attributes from the target?
>  
>  It would be straightforward to patch the above code to 'continue' on
>  both system and security attributes.  Something like:
>  
>  --- xattrs.c	2008-09-06 11:12:50.000000000 -0700
>  +++ xattrs.c.orig	2008-09-06 11:09:08.000000000 -0700
>  @@ -818,10 +818,9 @@
>   		list_len -= name_len;
>  
>   #ifdef HAVE_LINUX_XATTRS
>  -		/* 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) )
>  +		/* 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
>  
>  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.
>  
>  If not, I could use some "enlightenment"..... ;)
>  
>  tom 
We should bring this conversation into a bugzilla.  Maybe discuss on
main selinux list also.

[Tom London]

On Mon, Sep 8, 2008 at 5:46 AM, Daniel J Walsh <dwalsh(a)redhat.com&gt; wrote:
>  Tom London wrote:
> > On Wed, Sep 3, 2008 at 8:55 AM, James Antill <jantill(a)redhat.com&gt; wrote:
> >> On Wed, 2008-09-03 at 11:23 -0400, Daniel J Walsh wrote:
> >>
> >>> Looks like an rsync bug?
> >>>
> >>> James did you work on rsync?
> >>  Nope, looking at the rpm changelog shows:
> >>
> >>
> >> * Mon Feb 19 2007 Simo Sorce <ssorce(a)redhat.com&gt; - 2.6.9-2
> >> - fix acl/xattr bug with --delete: (bz#229145)
> >>
> >> [...]
> >>
> >> * Fri Jun 09 2006 Jay Fenlason <fenlason(a)redhat.com&gt; 2.6.8-3
> >> - Add my xattrs_bug patch to fix a bug where xattrs don't get sent
> >> correctly.
> >> [...]
> >>
> >> * Mon May 08 2006 Jay Fenlason <fenlason(a)redhat.com&gt; 2.6.8-2
> >> - New upstream release
> >> - Use the upstream xattr patch instead of mine.  This closes
> >>  bz#190208 CVE-2006-2083 rsync buffer overflow issue
> >>
> >> [...]
> >>
> >> * Thu Feb 10 2005 Jay Fenlason <fenlason(a)redhat.com&gt; 2.6.3-2
> >> - Added my -xattr patch, which is based on the -acl patch.
> >>
> >>
> >> --
> >> James Antill <jantill(a)redhat.com&gt;
> >> Red Hat
> >>
> > I looked into this a bit.....
> >
> > 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 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).
> >
> > Is this logic wrong?  Should rsync try to remove the security (e.g.,
> > selinux) attributes from the target?
> >
> > It would be straightforward to patch the above code to 'continue' on
> > both system and security attributes.  Something like:
> >
> > --- xattrs.c  2008-09-06 11:12:50.000000000 -0700
> > +++ xattrs.c.orig     2008-09-06 11:09:08.000000000 -0700
> > @@ -818,10 +818,9 @@
> >               list_len -= name_len;
> >
> >  #ifdef HAVE_LINUX_XATTRS
> > -             /* 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) )
> > +             /* 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
> >
> > 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.
> >
> > If not, I could use some "enlightenment"..... ;)
> >
> > tom
>  We should bring this conversation into a bugzilla.  Maybe discuss on
>  main selinux list also.
>  
BZ'ed (Fedora) here: https://bugzilla.redhat.com/show_bug.cgi?id=461486

I'll post something on tycho list too....

tom
-- 
Tom London