Bug 804243 - SELinux is preventing /usr/sbin/useradd from 'read' accesses on the lnk_file run.
SELinux is preventing /usr/sbin/useradd from 'read' accesses on the lnk_file ...
Status: CLOSED DUPLICATE of bug 858373
Product: Fedora
Classification: Fedora
Component: livecd-tools (Show other bugs)
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-03-16 19:45 EDT by Adam Williamson
Modified: 2012-10-09 14:14 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-10-09 14:14:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2012-03-16 19:45:12 EDT
libreport version: 2.0.8
executable:     /usr/bin/python
hashmarkername: setroubleshoot
kernel:         3.3.0-0.rc6.git0.2.fc17.x86_64
reason:         SELinux is preventing /usr/sbin/useradd from 'read' accesses on the lnk_file run.
time:           Fri 16 Mar 2012 04:45:04 PM PDT

:SELinux is preventing /usr/sbin/useradd from 'read' accesses on the lnk_file run.
:*****  Plugin catchall_labels (83.8 confidence) suggests  ********************
:If you want to allow useradd to have read access on the run lnk_file
:Then you need to change the label on run
:# semanage fcontext -a -t FILE_TYPE 'run'
:where FILE_TYPE is one of the following: var_run_t, httpd_user_script_exec_type, var_run_t, var_run_t, useradd_t, user_home_type, domain, abrt_t, lib_t, device_t, root_t, etc_runtime_t, ld_so_t, proc_t, home_root_t, textrel_shlib_t, cert_t, rpm_script_tmp_t, selinux_config_t, etc_t, user_home_dir_t, httpd_user_content_type, bin_t, cert_t, mail_spool_t, device_t, devlog_t, locale_t, usr_t, etc_t, var_run_t, proc_t, var_run_t, var_run_t. 
:Then execute: 
:restorecon -v 'run'
:*****  Plugin catchall (17.1 confidence) suggests  ***************************
:If you believe that useradd should be allowed read access on the run lnk_file by default.
:Then you should report this as a bug.
:You can generate a local policy module to allow this access.
:allow this access for now by executing:
:# grep useradd /var/log/audit/audit.log | audit2allow -M mypol
:# semodule -i mypol.pp
:Additional Information:
:Source Context                unconfined_u:system_r:useradd_t:s0-s0:c0.c1023
:Target Context                unconfined_u:object_r:var_t:s0
:Target Objects                run [ lnk_file ]
:Source                        useradd
:Source Path                   /usr/sbin/useradd
:Port                          <Unknown>
:Host                          (removed)
:Source RPM Packages           shadow-utils-
:Target RPM Packages           filesystem-3-2.fc17.x86_64
:Policy RPM                    selinux-policy-3.10.0-95.fc17.noarch
:Selinux Enabled               True
:Policy Type                   targeted
:Enforcing Mode                Enforcing
:Host Name                     (removed)
:Platform                      Linux (removed)
:                              3.3.0-0.rc6.git0.2.fc17.x86_64 #1 SMP Mon Mar 5
:                              16:54:07 UTC 2012 x86_64 x86_64
:Alert Count                   147
:First Seen                    Wed 14 Mar 2012 05:43:15 PM PDT
:Last Seen                     Fri 16 Mar 2012 02:05:39 PM PDT
:Local ID                      5179467d-9184-4545-a133-79a280ec10c6
:Raw Audit Messages
:type=AVC msg=audit(1331931939.959:2136): avc:  denied  { read } for  pid=8990 comm="useradd" name="run" dev="loop0" ino=1094 scontext=unconfined_u:system_r:useradd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file
:type=SYSCALL msg=audit(1331931939.959:2136): arch=x86_64 syscall=connect success=no exit=EACCES a0=5 a1=7fff90054d30 a2=6e a3=0 items=0 ppid=8974 pid=8990 auid=1001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=57 comm=useradd exe=/usr/sbin/useradd subj=unconfined_u:system_r:useradd_t:s0-s0:c0.c1023 key=(null)
:Hash: useradd,useradd_t,var_t,lnk_file,read
:audit2allowunable to open /sys/fs/selinux/policy:  Permission denied
:audit2allow -Runable to open /sys/fs/selinux/policy:  Permission denied
Comment 1 Adam Williamson 2012-03-16 19:46:06 EDT
So, this one happens I believe when I'm building a live image with livecd-creator. It's when an RPM %post script creates a user account, while that RPM is being installed into the mock environment where the live image is created.

Fedora Bugzappers volunteer triage team
Comment 2 Daniel Walsh 2012-03-17 06:56:04 EDT
Well theoretically this should not happen because everthing within the mock environment should be seeing SELinux as disabled.

I wonder if the rpm post install scripts see selinux outside the chroot, which is executing the transition.
Comment 3 John Florian 2012-10-05 08:50:16 EDT
(In reply to comment #2)
> Well theoretically this should not happen because everthing within the mock
> environment should be seeing SELinux as disabled.
> I wonder if the rpm post install scripts see selinux outside the chroot,
> which is executing the transition.

I was just looking into #858373 and this one for something relevant to an oddity I seeing related to selinux + livecd-tools.  Bug #858373 fit what I was seeing perfectly, except I only saw the AVC's for the very first run of livecd-creator.  If I rebooted the build host, the AVCs would return again, but only for the first run.

Getting to the point, the build host is configured to have SELinux in Enforcing mode by default.  I discovered that running livecd-creator is changing the SELinux to Permissive mode!  My kickstart has the directive "selinux --disabled" in it and if I comment that out, SELinux stays in Enforcing mode.  To get a rough idea of where the transition occurs, I've been running a "watch -n0.1 getenforce" concurrent with build via livecd-creator and have found it to switch into Permissive mode right around the time the %post of the kickstart is handled. (I've got a message there along with a sed to drop "quiet" and "rhgb" from the kernel boot options -- these happen very fast so the transition could be just before or after %post).

Anyway, I don't know if my observation pertains to this bug or if I should file a new one against livecd-creator, but comment 2 really seemed spot-on relevant.
Comment 4 John Florian 2012-10-05 09:01:25 EDT
I added a sleep to my kickstart's %post and can confirm that the transition happens after %post is finished.
Comment 5 Daniel Walsh 2012-10-09 14:13:13 EDT
Right livecd has the same problem that mock used to have.  There is an existing bug on this that hopefully will be fixed in livecd.
Comment 6 Daniel Walsh 2012-10-09 14:14:34 EDT

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

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