On Mon, Sep 8, 2008 at 5:46 AM, Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote:
> 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.
>
BZ'ed (Fedora) here: https://bugzilla.redhat.com/show_bug.cgi?id=461486
I'll post something on tycho list too....
tom
--
Tom London
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
