Hide Forgot
SELinux is preventing /usr/bin/kdm (deleted) from read, write access on the file .pam-systemd-lock. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that kdm (deleted) should be allowed read write access on the .pam-systemd-lock 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 kdm /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context system_u:object_r:crond_var_run_t:s0 Target Objects .pam-systemd-lock [ file ] Source kdm Source Path /usr/bin/kdm (deleted) Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.9.16-30.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.38.8-32.fc15.i686.PAE #1 SMP Mon Jun 13 19:55:27 UTC 2011 i686 i686 Alert Count 28 First Seen Sat 25 Jun 2011 10:52:53 PM EDT Last Seen Mon 04 Jul 2011 12:33:20 AM EDT Local ID 9385a9d2-1c8a-4d69-a79f-6e2491b2fe6b Raw Audit Messages type=AVC msg=audit(1309754000.789:58823): avc: denied { read write } for pid=31747 comm="kdm" name=".pam-systemd-lock" dev=tmpfs ino=22223 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:crond_var_run_t:s0 tclass=file type=SYSCALL msg=audit(1309754000.789:58823): arch=i386 syscall=open success=no exit=EACCES a0=136ea4 a1=a8142 a2=180 a3=8937520 items=0 ppid=2427 pid=31747 auid=500 uid=0 gid=100 euid=0 suid=0 fsuid=0 egid=100 sgid=100 fsgid=100 tty=(none) ses=8340 comm=kdm exe=2F7573722F62696E2F6B646D202864656C6574656429 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) Hash: kdm,xdm_t,crond_var_run_t,file,read,write audit2allow #============= xdm_t ============== allow xdm_t crond_var_run_t:file { read write }; audit2allow -R #============= xdm_t ============== allow xdm_t crond_var_run_t:file { read write };
/run/user/.pam-systemd-lock had context system_u:object_r:crond_var_run_t:s0. Running restorecon -v /run/user/.pam-systemd-lock resets context to system_u:object_r:var_run_t:s0 Not sure right now if the problem with kde will persist, but since /run/user/.pam-systemd-lock is recreated at boot and to my knowledge, I have done nothing to the system to cause the context to be system_u:object_r:crond_var_run_t:s0, I thinkk there must be a problem at creation.
Apparently there are lots of object created in /run with incorrect contexts. On my system a restorecon -Rvn /run | wc -l yields 504. /run/udev/ contains 394 of those.
Can you relabel your system and see if these files are still mislabeled?
Did a touch /.autorelabel and rebooted. /run/user/.pam-systemd-lock is back to system_u:object_r:crond_var_run_t:s0. restorecon -Rvn /run | wc -l only yielded 476 this time with 393 in /run/udev/. I am doing this remotely, so not everything may be started that would be with a local session.
John could you email me the output of restorecon? or give us an example of what is mislabeled?
Created attachment 511392 [details] contexts that restorecon would change in /run Attached output of restorecon.
The labels look correct and restorecon is breaking them. matchpathcon /run/faillock /run/faillock system_u:object_r:faillog_t:s0 cat /etc/selinux/targeted/contexts/files/file_contexts.subs /run /var/run /run/lock /var/lock /var/run/lock /var/lock
File /etc/selinux/targeted/contexts/files/file_contexts.subs exits but is zero bytes.
File is zero bytes on two different FC15 servers.
Comment 8: exits -> exists
The file is zero bytes on my FC14 server as well.
That is the problem, although I have no idea how that happened. # rm -f /etc/selinux/targeted/contexts/files/file_contexts.subs # yum reinstall selinux-policy-targeted Then see if the it has any content, if it does, try the restorecon test again.
No joy! /etc/selinux/targeted/contexts/files/file_contexts.subs still contains nothing. # yum reinstall selinux-policy-targeted . . . Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Reinstalling: selinux-policy-targeted noarch 3.9.16-30.fc15 updates 2.9 M Transaction Summary ================================================================================ Reinstall 1 Package(s) . . . Installed: selinux-policy-targeted.noarch 0:3.9.16-30.fc15 Complete! # cat /etc/selinux/targeted/contexts/files/file_contexts.subs # l /etc/selinux/targeted/contexts/files/file_contexts.subs -rw-r--r--. 1 root root 0 Jun 11 01:24 /etc/selinux/targeted/contexts/files/file
Sorry. Did not remove the file the first time. After removing the file and doing the reinstall, /etc/selinux/targeted/contexts/files/file_contexts.subs contains: /run /var/run /run/lock /var/lock /var/run/lock /var/lock and restorecon -Rvn /run | wc -l results in zero. These were fresh installations on the two FC15 servers, so somewhere along the line there must have been a zero byte /etc/selinux/targeted/contexts/files/file_contexts.subs installed. I have never edited or in anyway knowingly touched the file. As a note, removing /etc/selinux/targeted/contexts/files/file_contexts.subs on a FC14 system and reinstalling selinux-policy-targeted results in there being no /etc/selinux/targeted/contexts/files/file_contexts.subs file even though there was a zero byte one prior to removing it.
Ok maybe some rpm package is clearing this out via a bogus semanage command in post install. In F16 we have gone to two files for the subs. subs_dist for distributions and subs for local customizations. I guess I got to back port this to stop anyone from hosing up the system defaults.