[Discuss] apache

[markw at mohawksoft.com (markw at mohawksoft.com)]

If you suspect it may be selinux, try this:

run: "getenforce"

This will report whether or not SELINUX is enforcing. If it is in
ENFORCING, then it may.

Try setting it to "permissive" which will allow access but report it in
the audit log.

run: "setenforce 0"

Then re-run your operations. If they succeed then it is, in fact, SELINUX.

Then grep for "avc" in the audit log, dmesg, and journalctl. This will
display what access is denied and why.

At this point you can try "restorecon" to see if it is just that a file
was replaced and needs it context restored. If it is a new access pattern,
you can pipe the "avc" message through "audit2allow"

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-fixing_problems-allowing_access_audit2allow#sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow


> discuss-request at driftwood.blu.org writes:
>> From: Brandon Vogel <brandon.vogel at gmail.com>
>> Could it be selinux related possibly?
>
> Yeah, definitely check Selinux.  In general, daemons have lesser
> privileges than user-login processes precisely so they can't write into
> random files that happen to have broad write permissions.  I once gotten
> mysteriously bitten by this and it took me quite a while to track down
> (and figure out a workaround).  My vague memory is that they don't get
> the "unconfined" privileges.
>
> Dale
> _______________________________________________
> Discuss mailing list
> Discuss at lists.blu.org
> https://lists.blu.org/mailman/listinfo/discuss
>