On Wed, Sep 3, 2008 at 8:55 AM, James Antill <jantill@xxxxxxxxxx> 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@xxxxxxxxxx> - 2.6.9-2
> - fix acl/xattr bug with --delete: (bz#229145)
>
> [...]
>
> * Fri Jun 09 2006 Jay Fenlason <fenlason@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 2.6.3-2
> - Added my -xattr patch, which is based on the -acl patch.
>
>
> --
> James Antill <jantill@xxxxxxxxxx>
> 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
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
