Description of problem: Running rsync (all sorts of problems partially reported in 543062) also produces bogus error messages via sealert. The rsync being executed wants access to /etc /usr and /root and files under those directories, but wants no files at the root itself. Version-Release number of selected component (if applicable): f12 patched How reproducible: Using the environment and files reported in incident:543062 Steps to Reproduce: 1. 2. 3. Actual results: Summary: SELinux is preventing /usr/bin/rsync "read" access to /. Detailed Description: [rsync has a permissive type (rsync_t). This access was not denied.] SELinux denied access requested by rsync. / may be a mislabeled. / default SELinux type is root_t, but its current type is fusefs_t. Changing this file back to the default type, may fix your problem. Blah Blah Blah Additional Information: Source Context unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 Target Context system_u:object_r:fusefs_t:s0 Target Objects / [ dir ] Source rsync Source Path /usr/bin/rsync Port <Unknown> Host billlaptop.private.ycc Source RPM Packages rsync-3.0.6-3.fc12 Target RPM Packages filesystem-2.4.30-2.fc12 Policy RPM selinux-policy-3.6.32-46.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name restorecon Host Name billlaptop.private.ycc Platform Linux billlaptop.private.ycc 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 Alert Count 1 First Seen Tue 01 Dec 2009 11:14:05 AM CST Last Seen Tue 01 Dec 2009 11:14:05 AM CST Local ID 020b0813-4f5c-40df-97b8-ac82a55ce963 Line Numbers Raw Audit Messages node=billlaptop.private.ycc type=AVC msg=audit(1259687645.500:27080): avc: denied { read } for pid=13349 comm="rsync" name="/" dev=fuse ino=1 scontext=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fusefs_t:s0 tclass=dir node=billlaptop.private.ycc type=SYSCALL msg=audit(1259687645.500:27080): arch=c000003e syscall=21 success=yes exit=4294967424 a0=7fffe3cda0d0 a1=4 a2=1 a3=0 items=0 ppid=3123 pid=13349 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="rsync" exe="/usr/bin/rsync" subj=unconfined_u:system_r:rsync_t:s0-s0:c0.c1023 key=(null) Expected results: This is bogus. Here is the output from ls: root@billlaptop root# ls -aldZ / dr-xr-xr-x. root root system_u:object_r:root_t:s0 / Additional info: Note that what the alert says the context is, and what it really is are different. Also note that at the top of the alert it says : SELinux is preventing /usr/bin/rsync "read" access to /. and then a bit further it says: [rsync has a permissive type (rsync_t). This access was not denied.] then it says: SELinux denied access requested by rsync. so the messages are contradictory.
Actually the kernel is giving you the root of the mount point "/". Newer versions of setroubleshoot try to figure out the actual location of the device in the /proc/self/mountinfo.
All I'm trying to point out is that there shouldn't be an alert generated to begin with, and the text of the alert is wrong and contradictory. I can't set anything via selinux that I'm aware of to get rid of this nuisance alert. Somewhere, there has to be a setting, rule, etc that will allow rsync to not generate this type of response from selinux.
Are you sure rsync isn't trying to look at .gvfs directory in your homedir. How are you starting rsync any ways? Are you running it from stunnel or via inetd?
I have an empty .gvfs at /root. I have no idea what that directory represents or where it came from. I'm running the daemon from xinetd and running rsync from root's command line and root's crontab. rsync and selinux don't play well together, at least not as delivered in F12. I had to work through numerous selinux alerts and construct a set of rules too allow selinux to keep its mitts off rsync. Along the way I discovered an issue with the pre-xfer in the rsyncd.conf that I attempted to use. Selinux may be a good idea, but its current implementation leaves a lot to be desired. The damned thing just gets in the way too much.
getsebool -a | grep rsync rsync_client --> off rsync_export_all_ro --> off You might want to turn these booleans on. setsebool -P rsync_client=1 rsync_export_all_ro=1 If you remove the /root/.gvfs file, does the AVC go away?
I referenced incident 543062 way at the start of this thread. In that incident I show that I do use the rsync_export_all_ro =on before the rsync and =off after, and that I tried to build them into the rsyncd.conf file without success. I wasn't aware of rsync_client. I'll have to look that up. Using the rsync_export_all_ro =on still leads to the issue in this incident. I've tried to wrap my head around selinux several times without much success. The documentation was apparently written by lawyers accustomed to defining their own language to obfuscate what must be simple concepts. Selinux needs better documentation written to be understood by mere computer literate mortals, and then the game plan on how Selinux is currently set up needs to be divulged to provide a conceptual framework for why things are as they are and also to allow someone not intimately involved with it on a day to day basis to be able to catch on to the intent of all the rules and how everything hangs together. I have never found a reference for where all the files are stored, and how someone attacked the original problem of designing "The" rule set. A description of the process that can demonstrate how the rules evolved conceptually would be a real plus. As it is, from my perspective, it's a collection of spare parts rattling around the O/S and causing more grief that benefit at the moment. I know its lack of knowledge on my part, but I can't seem to acquire that knowledge from any of the documentation I've read. I really have tried.
Lets carry on the conversation in that bugzilla. *** This bug has been marked as a duplicate of bug 543062 ***