Bug 928582 - SELinux is preventing /usr/bin/touch from 'write' accesses on the directory lock.
Summary: SELinux is preventing /usr/bin/touch from 'write' accesses on the directory l...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 19
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:f3552813e0d1d4547f5f5ef3a73...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-28 01:45 UTC by sangu
Modified: 2013-04-19 05:54 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-19 05:54:20 UTC
Type: ---


Attachments (Terms of Use)

Description sangu 2013-03-28 01:45:02 UTC
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

Comment 1 Daniel Walsh 2013-03-28 18:01:11 UTC
Looks like /run/lock is mislabled.

restorecon -R -v /run/lock

Comment 2 Peter Trenholme 2013-03-29 18:46:00 UTC
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

Comment 3 sangu 2013-03-30 02:45:06 UTC
(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

Comment 4 Daniel Walsh 2013-04-01 14:27:33 UTC
Fixed in selinux-policy-3.12.1-25.fc19.noarch

Comment 5 Dawid Zamirski 2013-04-03 22:54:26 UTC
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

Comment 6 Tim Waugh 2013-04-04 08:14:56 UTC
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

Comment 7 Adam Williamson 2013-04-05 19:49:09 UTC
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

Comment 8 Ed Greshko 2013-04-06 04:34:28 UTC
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

Comment 9 Miroslav Grepl 2013-04-08 09:18:07 UTC
Fixed in selinux-policy-3.12.1-27.fc19

Comment 10 Fedora Update System 2013-04-08 11:43:03 UTC
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

Comment 11 Fedora Update System 2013-04-08 15:54:40 UTC
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).

Comment 12 Fedora Update System 2013-04-19 05:54:22 UTC
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.


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