Your original error messages make no sense with what you're showing for your cron that runs your logrotate
.
rotating pattern: /home/mail3/log/popMailProcessing.log forced from command line (60 rotations)
empty log files are rotated, old logs are removed
considering log /home//log/popMailProcessing.log
error: stat of /home/mail3/log/popMailProcessing.log failed: Permission denied
What are these paths doing going to /home/mail3/log/*
? Also what's missing from the /home//log/popMailProcessing.log
line? Seems like you're only showing some of the actual situation in your question.
Debugging the issue
Put this line in a shell script, logrotate.sh
:
#!/bin/bash
/usr/sbin/logrotate -f -v /etc/logrotate.d/mail3-logs &>> /var/log/logrotate/rotate.log
Make it executable and run it like this from the cron:
03 00 * * * root strace -s 2000 -o /tmp/strace.log /path/to/logrotate.bash
In going through the output you should see what is getting tripped up by the permissions problems.
EDIT #1
After conversing with the OP he mentioned that the above debugging technique uncovered that SELinux was enabled. He was perplexed as to why this was the case since he had previously disabled it with the command setenforce 0
.
Disabling SELinux in this fashion will only remain in this state until the next reboot. The default mode for SELinux is dictated by this file on Fedora/CentOS:
$ cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted
To permanently disable SELinux you'll want to change the line SELINUX=..
to one of the 3 states, enforcing
, permissive
, disabled
.
I would encourage you however to take the time to understand why SELinux is disallowing the access to the directory these log files are within, and add the appropriate context's so that SELinux allows this access. SELinux is an important part of the layered security model that is facilitated on Linux distros that make use of it, and blindly disabling it is taking one of the critical layers away.
References
I looks like at the time of this event that your /bin/dash
was associate with either an invalid or no selinux context at all.
Here lxc-attach complains that it failed to execute a shell:
lxc-attach: attach.c: lxc_attach_run_shell: 1325 Permission denied - failed to exec shell
The SELinux avc denial seems to confirm the above:
type=AVC msg=audit(1484836169.882:2969): avc: denied { entrypoint } for pid=7867 comm="lxc-attach" path="/bin/dash" dev="sda3" ino=10289 scontext=system_u:system_r:unconfined_service_t:s0 tcontext=unconfined_u:object_r:unlabeled_t:s0 tclass=file permissive=0
A few this to note in the event above:
The target file (path="/bin/dash"
) ended up with a special context (tcontext=unconfined_u:object_r:unlabeled_t:s0
) used by SELinux for failover scenarios. At the event either /bin/dash
located at inode 10289 on device sda3
was either associated with an invalid context, or no context at all.
Try to restorecon -RvF
the context of /bin/dash
at inode 10289 on device sda3
. After you've done that see if the context is reset to something other than unconfined_u:object_r:unlabeled_t:s0
with ls -alZ
Best Answer
When
cron
runslogrotate
, SELinux confines it to a logrotate_t "type". That "type" is restricted from modifying other file types (aka "escaping the confinement").When you run logrotate, you're (most likely) starting from an "unconfined" type, which means what it says -- the
logrotate
process is permitted to modify files. You might also wantlogrotate
to restart or signal processes (via postrotate, for example); that activity may also be confined by SELinux.My suggestion here is to tell SELinux to allow ("permit") the logrotate_t type to escape the confinement, with:
Doing so is a moderate solution, in-between turning SELinux off and fine-tuning a policy that allows exactly the confinement escapes that you need (perhaps with custom labeling). To revert this change, use
semanage permissive -d logrotate_t
.The best way to simulate a cron-initiated process is to put the jobs into cron. Alternatively, I'm aware of
runcon
, although I wasn't able to use it successfully.