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 description: :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 :Do :# 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. :Do :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-4.1.4.3-14.fc17.x86_64 :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 : :
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 https://fedoraproject.org/wiki/BugZappers
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.
(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.
I added a sleep to my kickstart's %post and can confirm that the transition happens after %post is finished.
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.
*** This bug has been marked as a duplicate of bug 858373 ***