"Daniel J Walsh wrote:" > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 01/22/2013 03:36 PM, David Highley wrote: > > "Daniel J Walsh wrote:" > >> > > On 01/22/2013 12:32 PM, David Highley wrote: > >>>> "Daniel J Walsh wrote:" > >>>>> > >>>> On 01/22/2013 09:39 AM, David Highley wrote: > >>>>>>> "Daniel J Walsh wrote:" > >>>>>>>> > >>>>>>> On 01/21/2013 06:13 PM, David Highley wrote: > >>>>>>>>>> "Daniel J Walsh wrote:" > >>>>>>>>>>> > >>>>>>>>>> On 01/21/2013 12:49 PM, David Highley wrote: > >>>>>>>>>>>>> "Daniel J Walsh wrote:" > >>>>>>>>>>>>>> > >>>>>>>>>>>>> On 01/18/2013 09:29 PM, David Highley wrote: > >>>>>>>>>>>>>>>> "David Highley wrote:" > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> "Daniel J Walsh wrote:" > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 01/18/2013 09:20 AM, David Highley wrote: > >>>>>>>>>>>>>>>>>>>> Upgraded a test box to Fedora 18 and > >>>>>>>>>>>>>>>>>>>> have tried to get rsync backups to it > >>>>>>>>>>>>>>>>>>>> working. Looked at many discussions > >>>>>>>>>>>>>>>>>>>> about backing up in a selinux > >>>>>>>>>>>>>>>>>>>> environment and all discussions > >>>>>>>>>>>>>>>>>>>> seemed to be incomplete. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Most indicate you should not keep > >>>>>>>>>>>>>>>>>>>> selinux labels, but none of those > >>>>>>>>>>>>>>>>>>>> discussion indicate what options to > >>>>>>>>>>>>>>>>>>>> change. After working on a thousand > >>>>>>>>>>>>>>>>>>>> line policy file I'm beginning to > >>>>>>>>>>>>>>>>>>>> think you just want to completely > >>>>>>>>>>>>>>>>>>>> turn off any audit of the rsync > >>>>>>>>>>>>>>>>>>>> domain. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Is this how we should approach > >>>>>>>>>>>>>>>>>>>> backups? If you do not preserve > >>>>>>>>>>>>>>>>>>>> selinux labels what should the backup > >>>>>>>>>>>>>>>>>>>> location get labeled to? > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I'm surprised as long as selinux has > >>>>>>>>>>>>>>>>>>>> been in use that a template with > >>>>>>>>>>>>>>>>>>>> details has not been defined for > >>>>>>>>>>>>>>>>>>>> this. By the way I had just submitted > >>>>>>>>>>>>>>>>>>>> an enhancement bug report for rsync > >>>>>>>>>>>>>>>>>>>> with examples of getting it to > >>>>>>>>>>>>>>>>>>>> function with systemd control. -- > >>>>>>>>>>>>>>>>>>>> selinux mailing list > >>>>>>>>>>>>>>>>>>>> selinux(a)lists.fedoraproject.org > >>>>>>>>>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>> > >>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>> > Does this help? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> http://danwalsh.livejournal.com/61646.html > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I had found and read this information, > >>>>>>>>>>>>>>>>>> but was not sure from it and the other > >>>>>>>>>>>>>>>>>> discussions that it was the right > >>>>>>>>>>>>>>>>>> direction and if the right direction that > >>>>>>>>>>>>>>>>>> it had complete information for doing the > >>>>>>>>>>>>>>>>>> implementation. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Has anyone tried this and has it worked > >>>>>>>>>>>>>>>>>> out? Do you define the backup area as > >>>>>>>>>>>>>>>>>> unconfined_u and relabel everything to > >>>>>>>>>>>>>>>>>> that? > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> OK, making rsync_t and unconfined domain > >>>>>>>>>>>>>>>>> gets rid of the AVCs. I still have concerns > >>>>>>>>>>>>>>>>> that it is just opening up a bad whole in > >>>>>>>>>>>>>>>>> the system. Is there a way of scoping it to > >>>>>>>>>>>>>>>>> only the back up area and or maybe forcing > >>>>>>>>>>>>>>>>> what ever is copied to a benign state by > >>>>>>>>>>>>>>>>> labeling it to something safe? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> -- selinux mailing list > >>>>>>>>>>>>>>>>> selinux(a)lists.fedoraproject.org > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>> > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > - -- selinux mailing list selinux(a)lists.fedoraproject.org > >>>>>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > Well rsync_t policy if for running rsync as a daemon not as a > >>>>>>>>>>>>> client. > >>>>>>>>>>>>> > >>>>>>>>>>>>> /usr/lib/systemd/system/rsyncd.service > >>>>>>>>>>>>> > >>>>>>>>>>>>> I just checked a fix into the policy so that only > >>>>>>>>>>>>> rsynd when run as a service will transition to > >>>>>>>>>>>>> rsync_t. But if you run it from a script or an > >>>>>>>>>>>>> application running as initrc_t, it will stay as > >>>>>>>>>>>>> the current domain. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, will check again when it is available. We > >>>>>>>>>>>>>> are using rsync as daemon spond by systemd. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> If you are only running rsync as a client, adding > >>>>>>>>>>>>> unconfined_domain(rsync_t) will not give it more > >>>>>>>>>>>>> privs that initrc_t already has. > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Ok then that is different, what is broken for you? > >>>>>>>>>> Without the unconfined_domain(rsync_t)? > >>>>>>>>>> > >>>>>>>>>> Sorry for the confusion. > >>>>>>>>>> > >>>>>>>>>>> OK, maybe the issue of confusion is what is the client > >>>>>>>>>>> and what is the server in the process. We have systems > >>>>>>>>>>> that we back up to, servers. They run rsyncd via > >>>>>>>>>>> systemd port activation requests. We have clients that > >>>>>>>>>>> run cron jobs to push back ups to one or more backup > >>>>>>>>>>> systems. > >>>>>>>>>> > >>>>>>>>>>> What we see with Fedora 18 selinux on the backup > >>>>>>>>>>> servers block everything. When I mean everything it > >>>>>>>>>>> seems to block almost all operations from getattr to > >>>>>>>>>>> relabel to unlink, name it, it is blocked. > >>>>>>>>>> > >>>>>>>>>>> This pretty much just worked for Fedora 16 and 17. > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> -- selinux mailing list selinux(a)lists.fedoraproject.org > >>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux > >>>>>>>>>> > >>>>>>> Could you send me a compresses audit.log? > >>>>>>> > >>>>>>>> Attached bzip2 file. > >>>>>>> > >>>>>>>> > >>>> > >>>> This looks like you are having your rsync server accepts files from > >>>> a remote machine and then writing them to anywhere on the local > >>>> machine. Meaning you really need to have rules like: > >>>> > >>>>> Not really, the rsync configuration file defines where the back ups > >>>>> go by system all under one directory. So one of my previous > >>>>> questions was can we identify that area to selinux? Sould we > >>>>> relabel the back up area? If we define it some how then we assume a > >>>>> complete relabel of the storage would do the right thing. > >>>> > >>>> > >>>> > >>>> allow rsync_t file_type:file create_file_perms; > >>>> > >>>> Or a boolean like ftp_full_access > >>>> > >>>> tunable_policy(`ftpd_full_access',` allow ftpd_t self:capability { > >>>> dac_override dac_read_search }; > >>>> files_manage_non_security_files(ftpd_t) ') > >>>> > >>>> FOr rsync. > >>>>> > > > > I thought the way you were supposed to use rsync was to pick a subdir > > where rsync would write its data to, and then label this rsync_data_t. But > > in your case it looks like the rsync server is trying to maintain the > > labels that it gets from the remote end? If it is not actually trying to > > overwrite local labels. > > > >> Ah, the answer I have been trying to get to. The policies expect the back > >> up area to be labeled rsync_data_t. So the fix is not to preserve labels > >> and to define to selinux the back up area by labeling it to rsync_data_t. > >> That should do it. In all the researching I never found or remember > >> seeing that the back up area should be labled rsync_data_t. Thanks > > > >> > > man rsync_selinux > ... > rsync_data_t > > - Set files with the rsync_data_t type, if you want to treat the files > as rsync content. Egg on face, somehow missed that information. Now if there were a better/faster way of relabeling the back up area. Still experimenting with rsync options as the man pages give no direct reference to selinux and the internet information indicates removing the -X option but were not sure that is enough. Thanks Dan for the help and support.

> > > -- selinux mailing list selinux(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

"David Highley wrote:" > > "David Highley wrote:" > > > > "Daniel J Walsh wrote:" > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > On 01/22/2013 03:36 PM, David Highley wrote: > > > > "Daniel J Walsh wrote:" > > > >> > > > > On 01/22/2013 12:32 PM, David Highley wrote: > > > >>>> "Daniel J Walsh wrote:" > > > >>>>> > > > >>>> On 01/22/2013 09:39 AM, David Highley wrote: > > > >>>>>>> "Daniel J Walsh wrote:" > > > >>>>>>>> > > > >>>>>>> On 01/21/2013 06:13 PM, David Highley wrote: > > > >>>>>>>>>> "Daniel J Walsh wrote:" > > > >>>>>>>>>>> > > > >>>>>>>>>> On 01/21/2013 12:49 PM, David Highley wrote: > > > >>>>>>>>>>>>> "Daniel J Walsh wrote:" > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>> On 01/18/2013 09:29 PM, David Highley wrote: > > > >>>>>>>>>>>>>>>> "David Highley wrote:" > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> "Daniel J Walsh wrote:" > > > >>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> On 01/18/2013 09:20 AM, David Highley wrote: > > > >>>>>>>>>>>>>>>>>>>> Upgraded a test box to Fedora 18 and > > > >>>>>>>>>>>>>>>>>>>> have tried to get rsync backups to it > > > >>>>>>>>>>>>>>>>>>>> working. Looked at many discussions > > > >>>>>>>>>>>>>>>>>>>> about backing up in a selinux > > > >>>>>>>>>>>>>>>>>>>> environment and all discussions > > > >>>>>>>>>>>>>>>>>>>> seemed to be incomplete. > > > >>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>> Most indicate you should not keep > > > >>>>>>>>>>>>>>>>>>>> selinux labels, but none of those > > > >>>>>>>>>>>>>>>>>>>> discussion indicate what options to > > > >>>>>>>>>>>>>>>>>>>> change. After working on a thousand > > > >>>>>>>>>>>>>>>>>>>> line policy file I'm beginning to > > > >>>>>>>>>>>>>>>>>>>> think you just want to completely > > > >>>>>>>>>>>>>>>>>>>> turn off any audit of the rsync > > > >>>>>>>>>>>>>>>>>>>> domain. > > > >>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>> Is this how we should approach > > > >>>>>>>>>>>>>>>>>>>> backups? If you do not preserve > > > >>>>>>>>>>>>>>>>>>>> selinux labels what should the backup > > > >>>>>>>>>>>>>>>>>>>> location get labeled to? > > > >>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>> I'm surprised as long as selinux has > > > >>>>>>>>>>>>>>>>>>>> been in use that a template with > > > >>>>>>>>>>>>>>>>>>>> details has not been defined for > > > >>>>>>>>>>>>>>>>>>>> this. By the way I had just submitted > > > >>>>>>>>>>>>>>>>>>>> an enhancement bug report for rsync > > > >>>>>>>>>>>>>>>>>>>> with examples of getting it to > > > >>>>>>>>>>>>>>>>>>>> function with systemd control. -- > > > >>>>>>>>>>>>>>>>>>>> selinux mailing list > > > >>>>>>>>>>>>>>>>>>>> selinux(a)lists.fedoraproject.org > > > >>>>>>>>>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux > > > >>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>> > > > >>>>>>> > > > >>>>>>>>>>>>>>>>>>>> > > > >>>> > > > >>>>>>>>>>>>>>>>>>>> > > > > > > > >>>>>>>>>>>>>>>>>>>> > > > Does this help? > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> http://danwalsh.livejournal.com/61646.html > > > >>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>> I had found and read this information, > > > >>>>>>>>>>>>>>>>>> but was not sure from it and the other > > > >>>>>>>>>>>>>>>>>> discussions that it was the right > > > >>>>>>>>>>>>>>>>>> direction and if the right direction that > > > >>>>>>>>>>>>>>>>>> it had complete information for doing the > > > >>>>>>>>>>>>>>>>>> implementation. > > > >>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>> Has anyone tried this and has it worked > > > >>>>>>>>>>>>>>>>>> out? Do you define the backup area as > > > >>>>>>>>>>>>>>>>>> unconfined_u and relabel everything to > > > >>>>>>>>>>>>>>>>>> that? > > > >>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> OK, making rsync_t and unconfined domain > > > >>>>>>>>>>>>>>>>> gets rid of the AVCs. I still have concerns > > > >>>>>>>>>>>>>>>>> that it is just opening up a bad whole in > > > >>>>>>>>>>>>>>>>> the system. Is there a way of scoping it to > > > >>>>>>>>>>>>>>>>> only the back up area and or maybe forcing > > > >>>>>>>>>>>>>>>>> what ever is copied to a benign state by > > > >>>>>>>>>>>>>>>>> labeling it to something safe? > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> -- selinux mailing list > > > >>>>>>>>>>>>>>>>> selinux(a)lists.fedoraproject.org > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux > > > >>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>> > > > >>>> > > > >>>>>>>>>>>>>>>>> > > > > > > > >>>>>>>>>>>>>>>>> > > > - -- selinux mailing list selinux(a)lists.fedoraproject.org > > > >>>>>>>>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux > > > >>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>> > > > > > > > >>>>>>>>>>>>>>>> > > > Well rsync_t policy if for running rsync as a daemon not as a > > > >>>>>>>>>>>>> client. > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> /usr/lib/systemd/system/rsyncd.service > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> I just checked a fix into the policy so that only > > > >>>>>>>>>>>>> rsynd when run as a service will transition to > > > >>>>>>>>>>>>> rsync_t. But if you run it from a script or an > > > >>>>>>>>>>>>> application running as initrc_t, it will stay as > > > >>>>>>>>>>>>> the current domain. > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>>> Thanks, will check again when it is available. We > > > >>>>>>>>>>>>>> are using rsync as daemon spond by systemd. > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> If you are only running rsync as a client, adding > > > >>>>>>>>>>>>> unconfined_domain(rsync_t) will not give it more > > > >>>>>>>>>>>>> privs that initrc_t already has. > > > >>>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>>> Ok then that is different, what is broken for you? > > > >>>>>>>>>> Without the unconfined_domain(rsync_t)? > > > >>>>>>>>>> > > > >>>>>>>>>> Sorry for the confusion. > > > >>>>>>>>>> > > > >>>>>>>>>>> OK, maybe the issue of confusion is what is the client > > > >>>>>>>>>>> and what is the server in the process. We have systems > > > >>>>>>>>>>> that we back up to, servers. They run rsyncd via > > > >>>>>>>>>>> systemd port activation requests. We have clients that > > > >>>>>>>>>>> run cron jobs to push back ups to one or more backup > > > >>>>>>>>>>> systems. > > > >>>>>>>>>> > > > >>>>>>>>>>> What we see with Fedora 18 selinux on the backup > > > >>>>>>>>>>> servers block everything. When I mean everything it > > > >>>>>>>>>>> seems to block almost all operations from getattr to > > > >>>>>>>>>>> relabel to unlink, name it, it is blocked. > > > >>>>>>>>>> > > > >>>>>>>>>>> This pretty much just worked for Fedora 16 and 17. > > > >>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>> -- selinux mailing list selinux(a)lists.fedoraproject.org > > > >>>>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux > > > >>>>>>>>>> > > > >>>>>>> Could you send me a compresses audit.log? > > > >>>>>>> > > > >>>>>>>> Attached bzip2 file. > > > >>>>>>> > > > >>>>>>>> > > > >>>> > > > >>>> This looks like you are having your rsync server accepts files from > > > >>>> a remote machine and then writing them to anywhere on the local > > > >>>> machine. Meaning you really need to have rules like: > > > >>>> > > > >>>>> Not really, the rsync configuration file defines where the back ups > > > >>>>> go by system all under one directory. So one of my previous > > > >>>>> questions was can we identify that area to selinux? Sould we > > > >>>>> relabel the back up area? If we define it some how then we assume a > > > >>>>> complete relabel of the storage would do the right thing. > > > >>>> > > > >>>> > > > >>>> > > > >>>> allow rsync_t file_type:file create_file_perms; > > > >>>> > > > >>>> Or a boolean like ftp_full_access > > > >>>> > > > >>>> tunable_policy(`ftpd_full_access',` allow ftpd_t self:capability { > > > >>>> dac_override dac_read_search }; > > > >>>> files_manage_non_security_files(ftpd_t) ') > > > >>>> > > > >>>> FOr rsync. > > > >>>>> > > > > > > > > I thought the way you were supposed to use rsync was to pick a subdir > > > > where rsync would write its data to, and then label this rsync_data_t. But > > > > in your case it looks like the rsync server is trying to maintain the > > > > labels that it gets from the remote end? If it is not actually trying to > > > > overwrite local labels. > > > > > > > >> Ah, the answer I have been trying to get to. The policies expect the back > > > >> up area to be labeled rsync_data_t. So the fix is not to preserve labels > > > >> and to define to selinux the back up area by labeling it to rsync_data_t. > > > >> That should do it. In all the researching I never found or remember > > > >> seeing that the back up area should be labled rsync_data_t. Thanks > > > > > > > >> > > > > > > man rsync_selinux > > > ... > > > rsync_data_t > > > > > > - Set files with the rsync_data_t type, if you want to treat the files > > > as rsync content. > > > > Egg on face, somehow missed that information. Now if there were a > > better/faster way of relabeling the back up area. Still experimenting > > with rsync options as the man pages give no direct reference to selinux > > and the internet information indicates removing the -X option but were > > not sure that is enough. Thanks Dan for the help and support. > > > > This stuff is never easy. We now have an equivalency rule blocking the > label change. What command removes the equivalency rule? > "Flat forhead, bald head"; the engineering methodology found solution. semanage fcontext -d </path> At least the label change stopped squawking.

> > > > > > > > > > > -- > > selinux mailing list > > selinux(a)lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/selinux > > > -- > selinux mailing list > selinux(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/selinux > -- selinux mailing list selinux(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEBoAsACgkQrlYvE4MpobN+9QCfY29xryibOIAUptx8cCQBGgSW /RAAn0ygr17F1baK8FxWhz9b5upEia3Y =f/Un -----END PGP SIGNATURE-----

To summarize what the solution was for doing rsync back ups on Fedora 18 where we have clients initiating rsync back ups via cron jobs to back up servers where rsync is run by connection requests via systemd control. - Stopped preserving selinux attributes by removing the -X option from the rsync command. - Relabel the back up storage are by doing an semanage fcontext -a -t rsync_data_t </path>'(/.*)?' - On the back up servers; setsebool -P rsync_client on We still ended up needing the following policy: policy_module(my_rsync, 1.0) require { type rsync_data_t; type rsync_t; class sock_file getattr; class capability net_admin; } #============= rsync_t ============== allow rsync_t rsync_data_t:sock_file getattr; allow rsync_t self:capability net_admin; Dan Walsh believes the last rule maybe a kernel bug which showed up today on Fedora 16 with kernel version 3.6.11-4 update. If you want to be able to query the back up server by doing an rsync <host>:: we need this rule for sshd: allow sshd_t rsync_data_t:file read; Should we submit any bug reports from this effort? If so, which subsystems should they be submitted against. Dan thank you for all the support effort to resolve these issues. -- selinux mailing list selinux(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEJIm0ACgkQrlYvE4MpobMKfwCbB/LYKN3ZqZb+brwXBR5anRJg 3zYAnitO+EPjpXLQ+zJ+hvMdtL2QwBbg =CLp6 -----END PGP SIGNATURE-----