Summary: SELinux is preventing /sbin/modprobe "read" access on /var/run/pm-utils/locks/pm-powersave.lock. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by modprobe. It is not expected that this access is required by modprobe and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:insmod_t:s0 Target Context system_u:object_r:hald_var_run_t:s0 Target Objects /var/run/pm-utils/locks/pm-powersave.lock [ file ] Source modprobe Source Path /sbin/modprobe Port <Unknown> Host (removed) Source RPM Packages module-init-tools-3.11.1-2.fc13 Target RPM Packages Policy RPM selinux-policy-3.9.1-2.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.35.4-12.fc14.x86_64 #1 SMP Fri Aug 27 07:45:05 UTC 2010 x86_64 x86_64 Alert Count 1 First Seen Fri 03 Sep 2010 01:38:04 PM PDT Last Seen Fri 03 Sep 2010 01:38:04 PM PDT Local ID 21a569ab-ab30-4ead-9065-8321ba6ac952 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1283546284.208:7): avc: denied { read } for pid=1701 comm="modprobe" path="/var/run/pm-utils/locks/pm-powersave.lock" dev=dm-3 ino=131720 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:object_r:hald_var_run_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1283546284.208:7): arch=c000003e syscall=59 success=yes exit=0 a0=2895b60 a1=28998d0 a2=2899580 a3=8 items=0 ppid=1692 pid=1701 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="modprobe" exe="/sbin/modprobe" subj=system_u:system_r:insmod_t:s0 key=(null) Hash String generated from catchall,modprobe,insmod_t,hald_var_run_t,file,read audit2allow suggests: #============= insmod_t ============== allow insmod_t hald_var_run_t:file read;
Some update to pm-utils is leaking like crazy. type=AVC msg=audit(1283530236.914:502): avc: denied { read } for pid=7288 comm="hdparm" path="/var/run/pm-utils/locks/pm-suspend.lock" dev=dm-1 ino=2081053 scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:object_r:hald_var_run_t:s0 tclass=file type=AVC msg=audit(1283537611.886:503): avc: denied { read } for pid=7473 comm="hdparm" path="/var/run/pm-utils/locks/pm-suspend.lock" dev=dm-1 ino=2081053 scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:object_r:hald_var_run_t:s0 tclass=file type=AVC msg=audit(1283537612.545:504): avc: denied { read } for pid=7535 comm="atd" path="/var/run/pm-utils/locks/pm-suspend.lock" dev=dm-1 ino=2081053 scontext=system_u:system_r:crond_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hald_var_run_t:s0 tclass=file
There was an update to pm-utils today. This is the yum history info for today's update transaction: Updated pm-utils-1.3.0-1.fc13.x86_64 Update 1.3.1-1.fc14.x86_64 The AVC denial happened during the first reboot after the update. Should I downgrade pm-utils and reboot? I see you switched this bug to pm-utils, thanks. Gene
>type=AVC msg=audit(1283530236.914:502): avc: denied { read } for pid=7288 comm="hdparm" path="/var/run/pm-utils/locks/pm-suspend.lock" dev=dm-1 I have no idea what this means.
Some app is opening /var/run/pm-utils/locks/pm-suspend.lock for read, and then executing lots of apps without closeing the app on exec. fcntl(fd, F_SETFD, FD_CLOEXEC) Will fix the problem. The question is do you know where the locks file is opened?
(In reply to comment #4) > Some app is opening /var/run/pm-utils/locks/pm-suspend.lock for read, and then > executing lots of apps without closeing the app on exec. > > fcntl(fd, F_SETFD, FD_CLOEXEC) > > Will fix the problem. The question is do you know where the locks file is > opened? It is a shell script that uses /usr/lib64/pm-utils/functions The try_lock function there creates the lock file.
Ok I will dontaudit these in the next release. Fixed in selinux-policy-3.9.3-1.fc14
*** Bug 630320 has been marked as a duplicate of this bug. ***
selinux-policy-3.9.3-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/selinux-policy-3.9.3-1.fc14
selinux-policy-3.9.3-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.9.3-1.fc14
*** Bug 632090 has been marked as a duplicate of this bug. ***
selinux-policy-3.9.3-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.