Description of problem: From env LANG=C LC_ALL=C sealert -l 647a47d2-7e4a-4cab-a8ce-724db303b1ce SELinux is preventing /usr/bin/bash from read access on the lnk_file /var/lock. ***** Plugin restorecon (94.8 confidence) suggests ************************* If you want to fix the label. /var/lock default label should be var_lock_t. Then you can run restorecon. Do # /sbin/restorecon -v /var/lock ***** Plugin catchall_labels (5.21 confidence) suggests ******************** If you want to allow bash to have read access on the lock lnk_file Then you need to change the label on /var/lock Do # semanage fcontext -a -t FILE_TYPE '/var/lock' where FILE_TYPE is one of the following: etc_runtime_t, udev_var_run_t, textrel_shlib_t, etc_t, cert_t, home_root_t, rpm_script_tmp_t, var_run_t, var_run_t, device_t, devlog_t, cgroup_t, locale_t, var_lock_t, dhcpc_t, etc_t, ypbind_t, bin_t, cert_t, proc_t, init_t, sysfs_t, nscd_t, ntpd_t, usr_t, dhcp_etc_t, var_run_t, device_t, net_conf_t, device_t, tmp_t, abrt_t, bin_t, ld_so_t, proc_t, lib_t, root_t, tmp_t, chronyd_t, proc_net_t, proc_xen_t, var_run_t, var_run_t, var_run_t. Then execute: restorecon -v '/var/lock' ***** Plugin catchall (1.44 confidence) suggests *************************** If you believe that bash should be allowed read access on the lock 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 dhclient-script /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:dhcpc_t:s0 Target Context system_u:object_r:var_t:s0 Target Objects /var/lock [ lnk_file ] Source dhclient-script Source Path /usr/bin/bash Port <Unknown> Host localhost.localdomain Source RPM Packages bash-4.2.37-2.fc17.i686 Target RPM Packages filesystem-3-2.fc17.i686 Policy RPM selinux-policy-3.10.0-149.fc17.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 3.5.3-1.fc17.i686 #1 SMP Wed Aug 29 19:25:38 UTC 2012 i686 i686 Alert Count 1 First Seen 2012-09-18 14:16:20 JST Last Seen 2012-09-18 14:16:20 JST Local ID 647a47d2-7e4a-4cab-a8ce-724db303b1ce Raw Audit Messages type=AVC msg=audit(1347945380.760:38): avc: denied { read } for pid=896 comm="dhclient-script" name="lock" dev="dm-1" ino=14123 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1347945380.760:38): arch=i386 syscall=stat64 success=no exit=EACCES a0=8db9208 a1=bfdeef40 a2=b7741ff4 a3=3 items=0 ppid=858 pid=896 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=dhclient-script exe=/usr/bin/bash subj=system_u:system_r:dhcpc_t:s0 key=(null) Hash: dhclient-script,dhcpc_t,var_t,lnk_file,read audit2allow #============= dhcpc_t ============== allow dhcpc_t var_t:lnk_file read; audit2allow -R #============= dhcpc_t ============== allow dhcpc_t var_t:lnk_file read; Version-Release number of selected component (if applicable): kernel-3.5.3-1.fc17.i686 selinux-policy-3.10.0-149.fc17.noarch dhclient-4.2.4-13.P2.fc17.i686 initscripts-9.37.1-1.fc17.i686 systemd-44-17.fc17.i686 How reproducible: Seems firstly occrred Steps to Reproduce: 1. boot (perhaps) 2. check /var/log/messages /var/log/audit/audit.log 3. Actual results: See above Expected results: No AVC denial Additional info: For my machine's settings, see "Additional info" of https://bugzilla.redhat.com/show_bug.cgi?id=858125#c0
*** Bug 858125 has been marked as a duplicate of this bug. ***
Does restorecon -v -R /var change the label on /var/lock?
(In reply to comment #2) > Does restorecon -v -R /var > change the label on /var/lock? Will try tomorrow.
Created attachment 614161 [details] restorecon result (In reply to comment #2) > Does restorecon -v -R /var > change the label on /var/lock? Looks like so (log attached). Maybe with usrmove /var/lock symlink is created during filesystem %postinstall, however selinux context was not correctly set?
There was some issues with usrmove where restorecon was needed as in this case.