Description of problem: SELinux is preventing /usr/bin/touch from 'write' accesses on the directory lock. ***** Plugin catchall (100. confidence) suggests *************************** If touch는 디폴트로 lock directory에서 write 액세스를 허용해야 합니다. Then 이 버그를 보고해야 합니다. 이러한 액세스를 허용하기 위해 로컬 정채 모듈을 생성할 수 있습니다. Do 지금 이 액세스를 허용하려면 다음을 실행합니다: # grep touch /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:mandb_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_run_t:s0 Target Objects lock [ dir ] Source touch Source Path /usr/bin/touch Port <Unknown> Host (removed) Source RPM Packages coreutils-8.21-8.fc19.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-24.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.8.4-202.fc18.x86_64 #1 SMP Thu Mar 21 17:02:20 UTC 2013 x86_64 x86_64 Alert Count 1 First Seen 2013-03-28 10:42:02 KST Last Seen 2013-03-28 10:42:02 KST Local ID 79b2e47d-1c2b-494d-a36c-1ab3b4557c44 Raw Audit Messages type=AVC msg=audit(1364434922.205:444): avc: denied { write } for pid=3430 comm="touch" name="lock" dev="tmpfs" ino=12774 scontext=system_u:system_r:mandb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=dir type=SYSCALL msg=audit(1364434922.205:444): arch=x86_64 syscall=open success=no exit=EACCES a0=7fff2b8c3f39 a1=941 a2=1b6 a3=7fff2b8c26c0 items=0 ppid=3426 pid=3430 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=2 tty=(none) comm=touch exe=/usr/bin/touch subj=system_u:system_r:mandb_t:s0-s0:c0.c1023 key=(null) Hash: touch,mandb_t,var_run_t,dir,write audit2allow #============= mandb_t ============== allow mandb_t var_run_t:dir write; audit2allow -R require { type mandb_t; } #============= mandb_t ============== files_rw_pid_dirs(mandb_t) Additional info: hashmarkername: setroubleshoot kernel: 3.8.4-202.fc18.x86_64 type: libreport
Looks like /run/lock is mislabled. restorecon -R -v /run/lock
Description of problem: Not sure, But, in any case, shouldn't any application be able to set and release locks? Additional info: hashmarkername: setroubleshoot kernel: 3.9.0-0.rc4.git0.1.fc19.x86_64 type: libreport
(In reply to comment #1) > Looks like /run/lock is mislabled. > > restorecon -R -v /run/lock Yesterday # ls -Z /run/lock drwxrwxr-x. root lock system_u:object_r:var_run_t:s0 lockdev drwx------. root root system_u:object_r:var_run_t:s0 lvm drwxr-xr-x. root root system_u:object_r:pppd_lock_t:s0 ppp drwxr-xr-x. root root system_u:object_r:var_run_t:s0 subsys # ls -Zd /run/lock drwxr-xr-x. root root system_u:object_r:var_run_t:s0 /run/lock # restorecon -R -v /run/lock/ restorecon reset /run/lock/ppp context system_u:object_r:pppd_lock_t:s0->system_u:object_r:var_run_t:s0 # ls -Zd /run/lock drwxr-xr-x. root root system_u:object_r:var_run_t:s0 /run/lock # ls -Z /run/lock drwxrwxr-x. root lock system_u:object_r:var_run_t:s0 lockdev drwx------. root root system_u:object_r:var_run_t:s0 lvm drwxr-xr-x. root root system_u:object_r:var_run_t:s0 ppp drwxr-xr-x. root root system_u:object_r:var_run_t:s0 subsys Today, this issue still happens. 3월 30 11:38:02 None anacron[4147]: Job `cron.daily' started 3월 30 11:38:02 None run-parts(/etc/cron.daily)[5817]: starting logrotate 3월 30 11:38:02 None run-parts(/etc/cron.daily)[5822]: finished logrotate 3월 30 11:38:02 None run-parts(/etc/cron.daily)[5824]: starting man-db.cron 3월 30 11:38:02 None setroubleshoot[791]: dbus avc(node=None type=AVC msg=audit(1364611082.323:449): avc: denied { write } for pid=5829 comm="touch" name="lock" dev="tmpfs" ino=6744 scontext=system_u:system_ 3월 30 11:38:02 None setroubleshoot[791]: AuditRecordReceiver.feed() got node=None type=AVC msg=audit(1364611082.323:449): avc: denied { write } for pid=5829 comm="touch" name="lock" dev="tmpfs" ino=6744 sco 3월 30 11:38:02 None setroubleshoot[791]: AuditRecordReceiver.add_record_to_cache(): node=None type=AVC msg=audit(1364611082.323:449): avc: denied { write } for pid=5829 comm="touch" name="lock" dev="tmpfs" 3월 30 11:38:02 None setroubleshoot[791]: AuditRecordReceiver.feed() got node=None type=SYSCALL msg=audit(1364611082.323:449): arch=c000003e syscall=2 success=no exit=-13 a0=7fff5fbfef39 a1=941 a2=1b6 a3=7fff5f 3월 30 11:38:02 None setroubleshoot[791]: AuditRecordReceiver.add_record_to_cache(): node=None type=SYSCALL msg=audit(1364611082.323:449): arch=c000003e syscall=2 success=no exit=-13 a0=7fff5fbfef39 a1=941 a2=1 3월 30 11:38:02 None setroubleshoot[791]: AuditRecordReceiver.feed() got node=None type=EOE msg=audit(1364611082.323:449): 3월 30 11:38:02 None setroubleshoot[791]: AuditRecordReceiver.add_record_to_cache(): node=None type=EOE msg=audit(1364611082.323:449): 3월 30 11:38:02 None setroubleshoot[791]: analyze_avc() avc=scontext=system_u:system_r:mandb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 access=['write'] tclass=dir tpath=lock 3월 30 11:38:02 None setroubleshoot[791]: lookup_signature: found 1 matches with scores 1.00 3월 30 11:38:02 None setroubleshoot[791]: signature found in database 3월 30 11:38:02 None setroubleshoot[791]: sending alert to all clients 3월 30 11:38:02 None setroubleshoot[791]: SELinux is preventing /usr/bin/touch from write access on the directory lock. For complete SELinux messages. run sealert -l a33e6d2e-4466-4652-8c0f-d32f9c705a6b
Fixed in selinux-policy-3.12.1-25.fc19.noarch
Description of problem: Pressed reload firewalld button in the Firewall configuration utility. Additional info: hashmarkername: setroubleshoot kernel: 3.9.0-0.rc4.git0.1.fc19.x86_64 type: libreport
Description of problem: Happened when man-db.cron ran. Additional info: hashmarkername: setroubleshoot kernel: 3.9.0-0.rc4.git0.1.fc19.x86_64 type: libreport
Description of problem: Happens on install and reboot of F19 Alpha TC5 KDE desktop live. No user interaction needed. Additional info: hashmarkername: setroubleshoot kernel: 3.9.0-0.rc4.git0.1.fc19.x86_64 type: libreport
Description of problem: Error occured while system idle in KDE Additional info: hashmarkername: setroubleshoot kernel: 3.9.0-0.rc4.git0.1.fc19.x86_64 type: libreport
Fixed in selinux-policy-3.12.1-27.fc19
selinux-policy-3.12.1-28.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/FEDORA-2013-5045/selinux-policy-3.12.1-28.fc19
Package selinux-policy-3.12.1-28.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-28.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5045/selinux-policy-3.12.1-28.fc19 then log in and leave karma (feedback).
selinux-policy-3.12.1-28.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.