[CentOS] Re: Need help with rsync. [solved]

Thu May 22 18:46:33 UTC 2008
James B. Byrne <byrnejb at harte-lyne.ca>

In-Reply-To: <f4e013870805211022r36194b29gb74ca4421dc2ee77 at mail.gmail.com>

On: Wed, 21 May 2008 10:22:19 -0700, MHR <mhullrich at gmail.com>

>> On Wed, May 21, 2008 at 8:37 AM, James B. Byrne <byrnejb at harte-lyne.ca>
>> wrote:
>> This indeed turned out to be an SELinux policy problem which I have since
>> resolved.
> Whoa, whoa, whoa, nice shooting, Tex!  (Ghostbusters)
> Not so fast - please post the solution, too, for posterity (and those
> of us who don't use SELinux but might, someday, in the not too distant
> far future...).
> Thanks.
> mhr

Dealings with SELinux issues typically do not lend themselves to short
answers.  SELinux is like an onion, each each exception blocks access until
resolved.  Thus each policy change has to be made individually and then the
process retested so that the next impediment evidences itself.

On CentOS-5 your friends are:

# grep avc /var/log/messages
# grep <process> /var/log/audit/audit.log

and some of the more useful utilities are:

# audit2allow
# audit2why
# chcon
# restorecon
# sealert
# semanage

When I suspect (and that is often the hardest part of the whole exercise,
realizing that SELinux is the problem) that SELinux is involved in a problem I
start by checking the system log file /var/log/messages with grep avc.  If I
see things like this:

# grep avc /var/log/messages

May 16 04:02:33 inet01 kernel: audit(1210924952.785:22973): avc:  denied  {
read } for  pid=22282 comm="prelink" name="setserial" dev=dm-0 ino=3309644
tcontext=system_u:object_r:rsync_data_t:s0 tclass=file

Then I infer that I have a problem with either the SELinux file contexts or
the system policy file.  If the SELinux problem is announced at the desktop
then you may also find it useful to check for this:

# grep setroubleshoot /var/log/messages

In which case you may see something like this:

Dec 17 14:13:24 inet01 setroubleshoot:
    SELinux is preventing /usr/sbin/httpd (httpd_t) "write" to virtual.d (etc_t).
    For complete SELinux messages. run sealert -l

In this case you can follow the suggestion given in the log message and run

# sealert -l 15618e2e-044c-4c4c-b3fc-ec1eba554d02
    SELinux is preventing /usr/sbin/httpd (httpd_t) "write" to virtual.d

Detailed Description
    SELinux is preventing /usr/sbin/httpd (httpd_t) "write" to virtual.d
    (etc_t). The SELinux type %TARGET_TYPE, is a generic type for all files in
    the directory and very few processes (SELinux Domains) are allowed to write
    ...   yada-yada-yada...
Allowing Access
    You can attempt to fix file context by executing restorecon -v virtual.d

    The following command will allow this access:
    restorecon virtual.d

And then you can try that, although I have rarely had a problem with SELinux
solved so simply:

# cd /path/to/virtual.d
# restorecon virtual.d

Anyway, if that does not work, or one never received an setroubleshoot report
to begin with, then I end up turning to audit2allow.  I do something like this
(where rsync is the process that I am having difficulty with, it could be
httpd, vsftp or anything else):

# grep rsync /var/log/audit/audit.log | audit2allow

Which may yield a report something like this:

#============= prelink_t ==============
allow prelink_t rsync_data_t:file read;

Now, if this does not look too alarming in terms of the access that rsync
seems to be seeking (being able to read files to be transferred seems a
logical enough expectation and the benefit/limitations of prelink seem to
require access in this instance) then we can add this permission to our policy
via a local module. You make one of these in this fashion:

#  grep rsync /var/log/audit/audit.log | audit2allow -M localrsyncmod

******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i localrsyncmod.pp

Again, you simply follow the instructions given in the report.

# semodule -i localrsyncmod.pp

Now you do yet another test and check the log files.  If the problem is fixed,
then great, you are finished.  Usually, however, SELinux issues continually
reveal one permission problem after another, sometimes with different
processes, until, at last, they have all been accommodated. Consequently you
end up re-running your tests, checking the audit files, and modifying the
local policy one item at a time.

Note that simply overriding what SELinux is prohibiting is not what I am
advocating here.  Sometimes the problem is that the software needs its file
system access expectations trimmed back and that requires filing a bug report
with the maintainers.  However, in a production environment you normally just
have to get things working and what I usually do is weigh what the program is
requesting against what I want it to do for me.  Often the problem is that the
default policy is simply too restrictive.  On rare occasions I do actually
file a bug report but almost always override the local policy anyway just to
get on with the job.

I hope this helps.

***          E-Mail is NOT a SECURE channel          ***
James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3