Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 226951 - SELinux is preventing /usr/sbin/useradd "read write" to faillog
Summary: SELinux is preventing /usr/sbin/useradd "read write" to faillog
Alias: None
Product: Fedora
Classification: Fedora
Component: shadow-utils
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Vrabec
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2007-02-02 08:27 UTC by Tim Lauridsen
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-02-14 22:04:45 UTC

Attachments (Terms of Use)

Description Tim Lauridsen 2007-02-02 08:27:50 UTC
Description of problem:

I got a SELinux alert on my just installed FC7 Test1 system

Version-Release number of selected component (if applicable):


How reproducible:

Dont know, the alert just popped up

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Here is the alert from the setroubleshoot browser

    SELinux is preventing /usr/sbin/useradd (useradd_t) "read write" to faillog

Detailed Description
    SELinux denied access requested by /usr/sbin/useradd. It is not expected
    that this access is required by /usr/sbin/useradd and this access may signal
    an intrusion attempt. It is also possible that the specific version or
    configuration of the application is causing it to require additional access.

Allowing Access
    Sometimes labeling problems can cause SELinux denials.  You could try to
    restore the default system file context for faillog, restorecon -v faillog
    If this does not work, there is currently no automatic way to allow this
    access. Instead,  you can generate a local policy module to allow this
    access - see Or you
    can disable SELinux protection altogether. Disabling SELinux protection is
    not recommended. Please file a against this package.

Additional Information        

Source Context                system_u:system_r:useradd_t
Target Context                system_u:object_r:var_log_t
Target Objects                faillog [ file ]
Affected RPM Packages         shadow-utils- [application]
Policy RPM                    selinux-policy-2.5.2-2.fc7
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.catchall_file
Host Name                     localhost
Platform                      Linux localhost 2.6.19-1.2914.fc7 #1 SMP Fri Jan
                              26 18:42:25 EST 2007 i686 athlon
Alert Count                   1
Line Numbers                  

Raw Audit Messages            

avc: denied { read, write } for comm="useradd" dev=sda3 egid=0 euid=0
exe="/usr/sbin/useradd" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="faillog"
pid=4076 scontext=system_u:system_r:useradd_t:s0 sgid=0
subj=system_u:system_r:useradd_t:s0 suid=0 tclass=file
tcontext=system_u:object_r:var_log_t:s0 tty=(none) uid=0

Comment 1 Peter Vrabec 2007-02-05 13:34:28 UTC
Daniel, could you look at this. I was able to reproduce it on rawhide, too.

Comment 2 Daniel Walsh 2007-02-05 20:15:31 UTC
The problem here is that /var/log/faillog is labeled incorrectly.  Some process
is recreating this file with the wrong context.  restorecon /var/log/faillog
will fix the files context and everything should work.  

Most likely a program removes the file and then recreates the file which would
adopt the context of the parent directory var_log_t instead of the defined
context faillog_t.

Comment 3 Peter Vrabec 2007-02-07 15:09:55 UTC
Tim, does restorecon help you?

Comment 4 Tim Lauridsen 2007-02-07 15:36:14 UTC
I have run the 'restorecon /var/log/faillog' command, but i only got the alert
once, i don't know what action triggered the alert.

Comment 5 Daniel Walsh 2007-02-14 22:04:45 UTC
This turned out to be an anaconda problem installation problem.  pam was being
installed before selinux-policy so files created in the post install were being
labeled incorrectly.  It is fixed in the next anaconda.

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