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

[Tom London]

On Mon, Sep 8, 2008 at 5:46 AM, Daniel J Walsh <dwalsh at redhat.com> wrote:
> Tom London wrote:
>> On Wed, Sep 3, 2008 at 8:55 AM, James Antill <jantill at 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 at redhat.com> - 2.6.9-2
>>> - fix acl/xattr bug with --delete: (bz#229145)
>>>
>>> [...]
>>>
>>> * Fri Jun 09 2006 Jay Fenlason <fenlason at 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 at 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 at redhat.com> 2.6.3-2
>>> - Added my -xattr patch, which is based on the -acl patch.
>>>
>>>
>>> --
>>> James Antill <jantill at 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 at tlondon ~]# getfattr /mnt/music
>> getfattr: /mnt/music: Operation not supported
>> [root at 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