Red Hat Bugzilla – Bug 168033
Design of rsync policy misconceived
Last modified: 2007-11-30 17:11:13 EST
The recent update to the rsyncd in -targeted seems to me to be ill conceived.
I'm filing this as a security bug because the effect of the new policy is to get
people to disable it in whole or in part.
Our server configuration is fairly typical of those that use rsyncd: we have
trees that are available via rsyncd that are ALSO available via the webserver.
There are two problems with using the ftpd_anon_t context for rsync:
1. The name makes no bloody sense, which is a security flaw in its
2. In our case, the files in question also need to be httpd_sys_content_t,
and they cannot be both.
I'm struck that perhaps we need a label that says "this file can be shown to the
world and I really don't care whether it is through apache, ftpd, tftpd, rsyncd,
or tin can and string." Perhaps "public_content_t". Alternatively, we may want a
boolean saying that rsync should accept httpd_sys_content_t as an alternative to
More generally, I'm struck that the selinux "one context per file" policy is
creating great difficulty in fashioning any sort of reasonable theory of
operation for how various overlapping programs like this should behave. What is
happening here is that the context selected is two narrow to cover the usage
pattern, with the consequence that selinux is getting in the way of successful
Is there a complete list of contexts somewhere, along with an explanation of
usage? Shouldn't there be one as part of the policy documentation?
Change ftpd_anon to public_content in rawhide.
httpd should be able to read public_content (ftpd_anon_t) files.
We have a domain anonymous_domain, which basically allows ftpd, apache, rsyncd
to expose this content.
I would prefer that you label you httpd_sys_content_t as public_content_t, then
add a boolean.
Fixed in selinux-policy-targeted-1.27.1-2.3