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 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.
On Sun, Aug 24, 2008 at 3:16 PM, Murray McAllister mmcallis@redhat.com 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
-----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?
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@redhat.com - 2.6.9-2 - fix acl/xattr bug with --delete: (bz#229145)
[...]
* Fri Jun 09 2006 Jay Fenlason fenlason@redhat.com 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@redhat.com 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@redhat.com 2.6.3-2 - Added my -xattr patch, which is based on the -acl patch.
On Wed, Sep 3, 2008 at 8:55 AM, James Antill jantill@redhat.com 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@redhat.com - 2.6.9-2
- fix acl/xattr bug with --delete: (bz#229145)
[...]
- Fri Jun 09 2006 Jay Fenlason fenlason@redhat.com 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@redhat.com 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@redhat.com 2.6.3-2
- Added my -xattr patch, which is based on the -acl patch.
-- James Antill jantill@redhat.com 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 wrote:
On Wed, Sep 3, 2008 at 8:55 AM, James Antill jantill@redhat.com 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@redhat.com - 2.6.9-2
- fix acl/xattr bug with --delete: (bz#229145)
[...]
- Fri Jun 09 2006 Jay Fenlason fenlason@redhat.com 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@redhat.com 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@redhat.com 2.6.3-2
- Added my -xattr patch, which is based on the -acl patch.
-- James Antill jantill@redhat.com 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.
On Mon, Sep 8, 2008 at 5:46 AM, Daniel J Walsh dwalsh@redhat.com wrote:
Tom London wrote:
On Wed, Sep 3, 2008 at 8:55 AM, James Antill jantill@redhat.com 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@redhat.com - 2.6.9-2
- fix acl/xattr bug with --delete: (bz#229145)
[...]
- Fri Jun 09 2006 Jay Fenlason fenlason@redhat.com 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@redhat.com 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@redhat.com 2.6.3-2
- Added my -xattr patch, which is based on the -acl patch.
-- James Antill jantill@redhat.com 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
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
James Antill -
Murray McAllister -
Tom London