This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 427150 - SELinux is preventing sshd (sshd_t) "append" to (var_log_t).
SELinux is preventing sshd (sshd_t) "append" to (var_log_t).
Status: CLOSED DUPLICATE of bug 427274
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
8
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-01 09:14 EST by astozzia
Modified: 2008-01-03 10:19 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-03 10:19:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description astozzia 2008-01-01 09:14:46 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
Comment 1 David Cornette 2008-01-01 10:49:33 EST
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.
Comment 2 Paul Howarth 2008-01-02 19:40:18 EST
Looks like a logrotate problem to me (Bug #427274)
Comment 3 Daniel Walsh 2008-01-03 10:19:45 EST
Yes nice catch.  Thanks Paul.



*** This bug has been marked as a duplicate of 427274 ***

Note You need to log in before you can comment on or make changes to this bug.