Hide Forgot
Description of problem: Attempting to start the apcupsd service results in SELinux is preventing /sbin/apcupsd 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 apcupsd 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: var_run_t, var_lock_t, bin_t, cert_t, device_t, devlog_t, locale_t, etc_t, proc_t, apcupsd_t, abrt_t, lib_t, root_t, var_run_t, device_t, ld_so_t, proc_t, mta_exec_type, textrel_shlib_t, rpm_script_tmp_t, init_t. Then execute: restorecon -v '/var/lock' ***** Plugin catchall (1.44 confidence) suggests *************************** If you believe that apcupsd 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 apcupsd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Version-Release number of selected component (if applicable): selinux-policy-3.9.16-23.fc15.noarch apcupsd-3.14.8-7.fc15 How reproducible: always Additional info: Seen on 2 machines (one i686 and one x86_64) with a F15 Final (AKA RC3) clean DVD install with all available updates applied.
Could you please enclose the whole report. You left out the informative part of it. You can probably also retrieve it by running: ausearch -m avc -ts today (provided that this event occurred today) Also can you please enclose output of the following commands: ps auxZ | grep apcupsd matchpatchcon /var/lock ls -dZ /var/lock sesearch --allow -s apcupsd_t -t var_lock_t -c lnk_file -p read (this command requires that package setools-console is installed i believe)
Thats "matchpathcon /var/lock". (i do that every time...)
I included the entire output of "sealert -l 08254268-3d94-453a-9aa0-415a847a3d30". Just noticed that if I click on sealert's "Notify Admin", it composes an email with additional info, below are the entire contents. I'm not sure which if any of the info you requested is missing, let me know and I'll add that as well. In any case, this should be reproducible on any F15 machine with the apcupsd package installed, by running "service apcupsd start". (I know I should be using systemd commands but I couldn't figure out the name of the service to use.) SELinux is preventing /sbin/apcupsd 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 apcupsd 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: var_run_t, var_lock_t, bin_t, cert_t, device_t, devlog_t, locale_t, etc_t, proc_t, apcupsd_t, abrt_t, lib_t, root_t, var_run_t, device_t, ld_so_t, proc_t, mta_exec_type, textrel_shlib_t, rpm_script_tmp_t, init_t. Then execute: restorecon -v '/var/lock' ***** Plugin catchall (1.44 confidence) suggests *************************** If you believe that apcupsd 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 apcupsd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:apcupsd_t:s0 Target Context system_u:object_r:var_t:s0 Target Objects /var/lock [ lnk_file ] Source apcupsd Source Path /sbin/apcupsd Port <Unknown> Host compaq-pc Source RPM Packages apcupsd-3.14.8-7.fc15 Target RPM Packages filesystem-2.4.40-1.fc15 Policy RPM selinux-policy-3.9.16-23.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name compaq-pc Platform Linux compaq-pc 2.6.38.6-27.fc15.x86_64 #1 SMP Sun May 15 17:23:28 UTC 2011 x86_64 x86_64 Alert Count 6 First Seen Thu 19 May 2011 06:50:20 PM EDT Last Seen Fri 20 May 2011 02:00:07 PM EDT Local ID 08254268-3d94-453a-9aa0-415a847a3d30 Raw Audit Messages type=AVC msg=audit(1305914407.551:312): avc: denied { read } for pid=5704 comm="apcupsd" name="lock" dev=dm-1 ino=4195866 scontext=system_u:system_r:apcupsd_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1305914407.551:312): arch=x86_64 syscall=open success=no exit=EACCES a0=23d81e0 a1=0 a2=23dc1e8 a3=64 items=0 ppid=1 pid=5704 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=apcupsd exe=/sbin/apcupsd subj=system_u:system_r:apcupsd_t:s0 key=(null) Hash: apcupsd,apcupsd_t,var_t,lnk_file,read audit2allow #============= apcupsd_t ============== allow apcupsd_t var_t:lnk_file read; audit2allow -R #============= apcupsd_t ============== allow apcupsd_t var_t:lnk_file read;
Thanks, the lnk_file at /var/lock is mislabeled. Running restorecon -R -v -F /var/lock should reset it to type var_lock_t. I think that one of the updates changed /var/lock to be a symbolic link, that its context was not restored by whatever package changed it and i suspect this will not happen with the final version of Fedora but i may be wrong. I thought the plan was to use bind mounts for this in F15 and use symbolic links in F16. mgrepl or dwalsh may have more details about this issue
Thanks, that appears to fix the sealert, but something else is also broken: [root@compaq-pc ~]# systemctl start apcupsd.service [root@compaq-pc ~]# systemctl status apcupsd.service apcupsd.service - LSB: apcupsd daemon Loaded: loaded (/etc/rc.d/init.d/apcupsd) Active: active (exited) since Fri, 20 May 2011 15:05:44 -0400; 4min 56s ago Process: 6935 ExecStop=/etc/rc.d/init.d/apcupsd stop (code=exited, status=0/SUCCESS) Process: 6951 ExecStart=/etc/rc.d/init.d/apcupsd start (code=exited, status=0/SUCCESS) Main PID: 1344 (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/apcupsd.service [root@compaq-pc ~]# and the apcupsd process is not running. Should I change the component to apcupsd?
I take it back, by stopping and restarting apcupsd.service again, I was able to reproduce what appears to be the identical sealert as before, so there still seems to be an selinux issue.
Can you enclose the "new" sealert please? It should not be the same.
OK, I ran [root@compaq-pc ~]# restorecon -R -v -F /var/lock [root@compaq-pc ~]# systemctl start apcupsd.service [root@compaq-pc ~]# systemctl status apcupsd.service apcupsd.service - LSB: apcupsd daemon Loaded: loaded (/etc/rc.d/init.d/apcupsd) Active: active (exited) since Fri, 20 May 2011 15:23:33 -0400; 15s ago Process: 7379 ExecStop=/etc/rc.d/init.d/apcupsd stop (code=exited, status=0/SUCCESS) Process: 7401 ExecStart=/etc/rc.d/init.d/apcupsd start (code=exited, status=0/SUCCESS) Main PID: 7175 (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/apcupsd.service [root@compaq-pc ~]# which caused the sealert SELinux is preventing /sbin/apcupsd 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 apcupsd 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: var_run_t, var_lock_t, bin_t, cert_t, device_t, devlog_t, locale_t, etc_t, proc_t, apcupsd_t, abrt_t, lib_t, root_t, var_run_t, device_t, ld_so_t, proc_t, mta_exec_type, textrel_shlib_t, rpm_script_tmp_t, init_t. Then execute: restorecon -v '/var/lock' ***** Plugin catchall (1.44 confidence) suggests *************************** If you believe that apcupsd 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 apcupsd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:apcupsd_t:s0 Target Context system_u:object_r:var_t:s0 Target Objects /var/lock [ lnk_file ] Source apcupsd Source Path /sbin/apcupsd Port <Unknown> Host compaq-pc Source RPM Packages apcupsd-3.14.8-7.fc15 Target RPM Packages filesystem-2.4.40-1.fc15 Policy RPM selinux-policy-3.9.16-23.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name compaq-pc Platform Linux compaq-pc 2.6.38.6-27.fc15.x86_64 #1 SMP Sun May 15 17:23:28 UTC 2011 x86_64 x86_64 Alert Count 3 First Seen Fri 20 May 2011 03:23:33 PM EDT Last Seen Fri 20 May 2011 03:23:33 PM EDT Local ID bcc760b1-6538-46f7-bbac-26df388b9578 Raw Audit Messages type=AVC msg=audit(1305919413.836:365): avc: denied { read } for pid=7409 comm="apcupsd" name="lock" dev=dm-1 ino=4195866 scontext=system_u:system_r:apcupsd_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1305919413.836:365): arch=x86_64 syscall=open success=no exit=EACCES a0=11981e0 a1=0 a2=119c1e8 a3=64 items=0 ppid=1 pid=7409 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=apcupsd exe=/sbin/apcupsd subj=system_u:system_r:apcupsd_t:s0 key=(null) Hash: apcupsd,apcupsd_t,var_t,lnk_file,read audit2allow #============= apcupsd_t ============== allow apcupsd_t var_t:lnk_file read; audit2allow -R #============= apcupsd_t ============== allow apcupsd_t var_t:lnk_file read;
Please run the following commands and enclose the output: matchpathcon /var/lock ls -alZ /var | grep lock semanage fcontext -l | grep var_lock_t
[root@compaq-pc ~]# matchpathcon /var/lock /var/lock system_u:object_r:var_lock_t:s0 [root@compaq-pc ~]# ls -alZ /var | grep lock lrwxrwxrwx. root root system_u:object_r:var_t:s0 lock -> ../run/lock [root@compaq-pc ~]# semanage fcontext -l | grep var_lock_t /run/lock(/.*)? all files system_u:object_r:var_lock_t:s0 /var/lock symbolic link system_u:object_r:var_lock_t:s0 /var/lock(/.*)? all files system_u:object_r:var_lock_t:s0 /var/lock/dirsrv(/.*)? all files system_u:object_r:dirsrv_var_lock_t:s0 /var/lock/subsys/denyhosts regular file system_u:object_r:denyhosts_var_lock_t:s0 [root@compaq-pc ~]#
Can you also please run the following commands (again) and enclose the output: restorecon -R -v -F /var/lock ls -alZ /var | grep lock
[root@compaq-pc ~]# restorecon -R -v -F /var/lock [root@compaq-pc ~]# ls -alZ /var | grep lock lrwxrwxrwx. root root system_u:object_r:var_t:s0 lock -> ../run/lock [root@compaq-pc ~]#
That is just strange indeed. Please try the following (in this order) and paste output: chcon -t var_lock_t /var/lock ls -alZ /var | grep lock restorecon -R -v -F /var/lock
[root@compaq-pc ~]# chcon -t var_lock_t /var/lock [root@compaq-pc ~]# ls -alZ /var | grep lock lrwxrwxrwx. root root system_u:object_r:var_t:s0 lock -> ../run/lock [root@compaq-pc ~]# restorecon -R -v -F /var/lock [root@compaq-pc ~]#
Ok i think i found the issue (hopefully) Please try this instead: chcon -v -t var_lock_t /var/lock ls -alZ var | grep lock restorecon -R -v -F /var/lock
[root@compaq-pc ~]# chcon -v -t var_lock_t /var/lock changing security context of `/var/lock' [root@compaq-pc ~]# ls -alZ var | grep lock ls: cannot access var: No such file or directory [root@compaq-pc ~]# ls -alZ /var | grep lock lrwxrwxrwx. root root system_u:object_r:var_t:s0 lock -> ../run/lock [root@compaq-pc ~]# restorecon -R -v -F /var/lock [root@compaq-pc ~]#
Whoops sorry i meant: chcon -h -t var_lock_t /var/lock ls -alZ /var | lock restorecon -R -v -F /var/lock
[root@compaq-pc ~]# chcon -h -t var_lock_t /var/lock [root@compaq-pc ~]# ls -alZ /var | lock bash: lock: command not found... [root@compaq-pc ~]# ^C [root@compaq-pc ~]# ls -alZ /var | grep lock lrwxrwxrwx. root root system_u:object_r:var_lock_t:s0 lock -> ../run/lock [root@compaq-pc ~]# restorecon -R -v -F /var/lock [root@compaq-pc ~]#
I can also run apcupsd now: [root@compaq-pc ~]# systemctl start apcupsd.service [root@compaq-pc ~]# systemctl status apcupsd.service apcupsd.service - LSB: apcupsd daemon Loaded: loaded (/etc/rc.d/init.d/apcupsd) Active: active (running) since Fri, 20 May 2011 15:55:50 -0400; 5s ago Process: 7501 ExecStop=/etc/rc.d/init.d/apcupsd stop (code=exited, status=0/SUCCESS) Process: 7928 ExecStart=/etc/rc.d/init.d/apcupsd start (code=exited, status=0/SUCCESS) Main PID: 7935 (apcupsd) CGroup: name=systemd:/system/apcupsd.service └ 7935 /sbin/apcupsd -f /etc/apcupsd/apcupsd.conf [root@compaq-pc ~]# ps -A | grep apcupsd 7935 ? 00:00:00 apcupsd [root@compaq-pc ~]# apcaccess APC : 001,035,0886 DATE : 2011-05-20 15:55:51 -0400 HOSTNAME : compaq-pc VERSION : 3.14.8 (16 January 2010) redhat UPSNAME : compaq-pc CABLE : USB Cable MODEL : Back-UPS ES 650 UPSMODE : Stand Alone STARTTIME: 2011-05-20 15:55:50 -0400 STATUS : ONLINE LINEV : 120.0 Volts LOADPCT : 23.0 Percent Load Capacity BCHARGE : 100.0 Percent TIMELEFT : 22.6 Minutes MBATTCHG : 5 Percent MINTIMEL : 3 Minutes MAXTIME : 0 Seconds SENSE : Medium LOTRANS : 088.0 Volts HITRANS : 139.0 Volts ALARMDEL : Always BATTV : 13.5 Volts LASTXFER : No transfers since turnon NUMXFERS : 0 TONBATT : 0 seconds CUMONBATT: 0 seconds XOFFBATT : N/A STATFLAG : 0x07000008 Status Flag MANDATE : 2009-11-17 SERIALNO : 4B0953290924 BATTDATE : 2009-11-17 NOMINV : 120 Volts NOMBATTV : 12.0 Volts FIRMWARE : 842.J3 .D USB FW:J3 APCMODEL : Back-UPS ES 650 END APC : 2011-05-20 15:56:36 -0400 [root@compaq-pc ~]#
can you give me the full path to the apcupsd lock file please? It is missing a file context specification in the policy
It is just so weird/ not natural that restorecon -R -v -F does not restore the /var/lock symlink context.
(In reply to comment #20) > can you give me the full path to the apcupsd lock file please? It is missing a > file context specification in the policy Not sure if this is what you want: [root@compaq-pc ~]# ls -l /var/lock lrwxrwxrwx. 1 root root 11 May 19 04:29 /var/lock -> ../run/lock [root@compaq-pc ~]# ls -l /run/lock total 4 -rw-r--r--. 1 root root 11 May 20 15:55 LCK.. drwxrwxr-x. 2 root lock 40 May 19 18:50 lockdev drwx------. 2 root root 40 May 19 18:50 lvm drwxr-xr-x. 2 root root 520 May 20 15:55 subsys [root@compaq-pc ~]#
i mean the actual lock file "var/lock/subsys/apcupsd" i suspect? ls -alZ /var/lock/subsys/apcupsd
Apparently so: [root@compaq-pc ~]# ls -alZ /var/lock/subsys/apcupsd -rw-r--r--. root root system_u:object_r:var_lock_t:s0 /var/lock/subsys/apcupsd [root@compaq-pc ~]#
Well this issue may or may not be resolved in Fedora yet. Lets see what the others have to say about restorecon not restoring the /var/lock symlink. I did however add a file context specification for /var/lock/subsys/apcupsd to the rawhide policy. http://git.fedorahosted.org/git/?p=selinux-policy.git;a=commitdiff;h=e9bba73123846b9a1e9355fb138a184a775be7e9
As mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=706489#c0 , this was a clean install from the Fedora 15 Final (AKA RC3) DVD with all available updates applied, so it's not resolved until there's an update pushed to stable.
*** This bug has been marked as a duplicate of bug 698223 ***