Tom London wrote:
> 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
We should bring this conversation into a bugzilla. Maybe discuss on
main selinux list also.
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
