Red Hat Bugzilla – Bug 427150
SELinux is preventing sshd (sshd_t) "append" to (var_log_t).
Last modified: 2008-01-03 10:19:45 EST
Description of problem: SELinux is preventing sshd (sshd_t) "append" to (var_log_t) The SELinux type var_log_t, is a generic type for all files in the directory and very few processes (SELinux Domains) are allowed to write to this SELinux type. This type of denial usual indicates a mislabeled file. By default a file created in a directory has the gets the context of the parent directory, but SELinux policy has rules about the creation of directories, that say if a process running in one SELinux Domain (D1) creates a file in a directory with a particular SELinux File Context (F1) the file gets a different File Context (F2). The policy usually allows the SELinux Domain (D1) the ability to write, unlink, and append on (F2). But if for some reason a file () was created with the wrong context, this domain will be denied. The usual solution to this problem is to reset the file context on the target file, restorecon -v . If the file context does not change from var_log_t, then this is probably a bug in policy. Version-Release number of selected component (if applicable):setroubleshoot 1.10.7 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Source Context: system_u:system_r:sshd_t:s0-s0:c0.c1023Target Context: system_u:object_r:var_log_t:s0Target Objects: None [ file ]Affected RPM Packages: Policy RPM: selinux-policy-3.0.8-72.fc8Selinux Enabled: TruePolicy Type: targetedMLS Enabled: TrueEnforcing Mode: EnforcingPlugin Name: plugins.mislabeled_file
I had the same problem on my newly installed Fedora 8 system. This is actually a fairly big problem, because the every few seconds, it causes the denial notification message to pop up with no obvious way to stop it apparent. I got the messages to stop by doing "restorecon -v /var/log/*" as root. the output was as follows: restorecon reset /var/log/btmp context system_u:object_r:var_log_t:s0->system_u:object_r:faillog_t:s0 restorecon reset /var/log/rpmpkgs context system_u:object_r:var_log_t:s0->system_u:object_r:rpm_log_t:s0 restorecon reset /var/log/yum.log context system_u:object_r:var_log_t:s0->system_u:object_r:rpm_log_t:s0 Since there are some yum and rpm related things there, it may be worth mentioning that I had left yumex open overnight. As I said, this is a newly installed, last night was the first time cron.monthly would have run.
Looks like a logrotate problem to me (Bug #427274)
Yes nice catch. Thanks Paul. *** This bug has been marked as a duplicate of 427274 ***