Bug 458014

There are no AVC denials on either system.

Yup, I can confirm this.

Source
$ uname -r
2.6.27.21-170.2.56.fc10.i686
Target
# uname -r
2.6.26.8-57.fc8

rsync: rsync_xal_set: lsetxattr(".","security.selinux") failed: Invalid argument (22)

Here's links to my posts to rsync mail list that describes an -X failure to preserve SELinux with error (22):
http://lists.samba.org/archive/rsync/2009-April/022996.html
http://lists.samba.org/archive/rsync/2009-April/023150.html

Here's a bug I'm about to re-open because I don't see "that the "lsetxattr" failure is caused by a fundamental change in the file system data structures implementing extended SELinux file attributes between Linux kernels" 2.6.26 and 2.6.27, which is the implication of the reason for closing the bug:
https://bugzilla.samba.org/show_bug.cgi?id=5356

Couldn't re-open, so here's the new bug:
https://bugzilla.samba.org/show_bug.cgi?id=6312

You have to understand that SELinux labels are not defined in the kernel, but *loaded* in the kernel at startup sourcing from the policy files.

So first test would be do rsync from one directory to another of the same machine (as root with all necessary capabilities) and checking if SELinux attributes are preserved (try on both machines). If there are failures on the same machine then we can start considering whether it is an rsync bug or a bad SELinux policy preventing rsync from doing its job correctly.

Created attachment 342167 [details]
See Comment #7

Created attachment 342168 [details]
See Comment #7

Ooops, looks like that should have been see Comment #7

Done that, output attached.  Source machine is RsyncMM and Target is RsyncMOM.

Sort answer, no - no failures of either machine.

Ran "rsync -avzAXH --delete-after" on each machine.

But, from memory - a few months ago - I did run rsync -avzAXH against /etc on the Target machine (MOM), more or less as attached, and did get some errors.  They may have been the (95) failures, but those were all beagle problems which wouldn't be relevant to /etc .  At that time I was mounting the Target drive (bigdisk) via gnome vfs.  Now its mounted at boot with the options "defaults,acl,user_xattr" in fstab.

*** Bug 496552 has been marked as a duplicate of this bug. ***

Error 22 is EINVAL, can you please post which selinux policy you have installed on both machine and exactly what file causes that error?
I really suspect it is because one of the 2 systems has a label the other knows nothing about.
Let's try to see if this is true.

Syncing to a directory on the same machine seems to preserve the context now, but an error still occurs:

* Red Hat Enterprise Linux Client release 5.3 (Tikanga)
* rsync-2.6.8-3.1 (same version as comment #0)
* selinux-policy-2.4.6-203.el5
* selinux-policy-targeted-2.4.6-203.el5

1. cd
2. touch file1 && chcon -t httpd_sys_content_t file1 && mkdir b
3. ls -lZ file1
-rw-rw-r--  mmcallis mmcallis user_u:object_r:httpd_sys_content_t file1
4. ls -ldZ b
drwxrwxr-x  mmcallis mmcallis user_u:object_r:user_home_t      b
5. rsync -avHPAX file1 b/
building file list ... 
1 file to consider
file1
           0 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/1)
set_acl: sys_acl_get_file(.file1.T8WYMk, SMB_ACL_TYPE_ACCESS): Operation not supported

sent 198 bytes  received 42 bytes  480.00 bytes/sec
total size is 0  speedup is 0.00
rsync error: some files could not be transferred (code 23) at main.c(892) [sender=2.6.8]
6. ls -lZ b/file1 
-rw-rw-r--  mmcallis mmcallis user_u:object_r:httpd_sys_content_t b/file1 (context preserved)

bah, forget it was reported against Fedora. Please ignore comment #10

On Fedora 10 with:
* rsync-3.0.5-1.fc10.i386
* selinux-policy-3.5.13-57.fc10.noarch
* selinux-policy-targeted-3.5.13-57.fc10.noarch

doing same steps as comment #10

$ rsync -avHPAX file1 b/
sending incremental file list
file1
           0 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/1)

sent 125 bytes  received 31 bytes  312.00 bytes/sec
total size is 0  speedup is 0.00
[murray@localhost ~]$ ls -lZ b/file1 
-rw-rw-r--  murray murray unconfined_u:object_r:user_home_t:s0 b/file1

looks like no errors and context not preserved.

From comment #4, when done on Fedora 10 as the root user, the context is preserved when syncing to a directory on the local machine.

Was the test on RHEL done as user or as root ?

comment #10 was done as a standard user (user_u:system_r:unconfined_t)

Created attachment 342288 [details]
See Comment #16

Re Comment #9

[root@morgansoldmachine ~]# rpm -q selinux-policy
selinux-policy-3.0.8-127.fc8
[morgan@morgansmachine Desktop]$ rpm -q selinux-policy
selinux-policy-3.5.13-55.fc10.noarch

"exactly what file causes that error"...
See attachment, too many to mention - too many for my terminal window, added back in the command at top of terminal out-put

You can't set selinux labels as user it's the whole point of MAC (Mandatory Access Control), if you could set labels yourself SELinux would be useless.

I am marking this as NOTABUG unless setting SELinux attributes fails as root.

I believe it is acceptable for a user to set certain (not all, of course) labels on files in their home directories, such as httpd_sys_content_t on their public_html/ directory. Will try to open a bug against selinux-policy; diffing rsync.te from Fedora and Red Hat Enterprise Linux showed policy version shipped with Red Hat Enterprise Linux having more rules, so maybe that is the problem?

Thanks.

Hmm, maybe not "acceptable" but it works.

Created attachment 342435 [details]
RsyncMM>MOMroot>root

Re Comment #17

Sorry, I'm confused - how am I setting selinux labels; how do I avoid doing so?  I'm running rsync as root, not user - unless sudo counts as user rather than root?  If I can't avoid setting selinux labels as user running rsync, what's the point of -X?

Attached is the same out put as for Comment #16, but run simply root to root - so how can I be setting anything as any user, other than root?

(In reply to comment #20)
> Created an attachment (id=342435) [details]
> RsyncMM>MOMroot>root
> 
> Re Comment #17
> 
> Sorry, I'm confused - how am I setting selinux labels; how do I avoid doing so?
>  I'm running rsync as root, not user - unless sudo counts as user rather than
> root?  If I can't avoid setting selinux labels as user running rsync, what's
> the point of -X?
> 
> Attached is the same out put as for Comment #16, but run simply root to root -
> so how can I be setting anything as any user, other than root?  

Sorry Morgan,
your and Murray reports got mingled and I assumed both of you used a normal user after Murray reply.

Now back to the file list, can you pick one of the files that gives you an error and do an ls -aLZ on the source machine and report what SELinux context it reports ?

if you try as root to use chcon to set that same SELinux context on a file on the target machine does it succeed? Or do you get an error? if so what error ?

To me it seem all user browser confinement stuff and if I am right you will find that chcon will fail on the target machine simply because these labels are unknown there. Can you confirm please ?

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

I've been running f10 for my comments above - so please re-open.  I'll get onto it soon...  Busy, busy, busy.  Thanks

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.