SELinux is preventing /usr/bin/gnome-power-manager from 'getattr' accesses on the sock_file /tmp/at-spi2/socket-1385-1804289383. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that gnome-power-manager should be allowed getattr access on the socket-1385-1804289383 sock_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 gnome-power-man /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:tmp_t:s0 Target Objects /tmp/at-spi2/socket-1385-1804289383 [ sock_file ] Source gnome-power-man Source Path /usr/bin/gnome-power-manager Port <Unknown> Host (removed) Source RPM Packages gnome-power-manager-2.91.93-1.fc15 Target RPM Packages Policy RPM selinux-policy-3.9.16-10.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.38.2-9.fc15.x86_64 #1 SMP Wed Mar 30 16:55:57 UTC 2011 x86_64 x86_64 Alert Count 1 First Seen Fri 01 Apr 2011 08:00:59 AM PDT Last Seen Fri 01 Apr 2011 08:00:59 AM PDT Local ID b13a00f2-9eea-4ab9-8410-9f3beeef90aa Raw Audit Messages type=AVC msg=audit(1301670059.533:60): avc: denied { getattr } for pid=1385 comm="gnome-power-man" path="/tmp/at-spi2/socket-1385-1804289383" dev=sdb6 ino=272644 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file type=SYSCALL msg=audit(1301670059.533:60): arch=x86_64 syscall=stat success=no exit=EACCES a0=197a1c0 a1=7fff2c1fde80 a2=7fff2c1fde80 a3=393832343038312d items=0 ppid=1 pid=1385 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 tty=(none) ses=4294967295 comm=gnome-power-man exe=/usr/bin/gnome-power-manager subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) Hash: gnome-power-man,xdm_t,tmp_t,sock_file,getattr audit2allow #============= xdm_t ============== allow xdm_t tmp_t:sock_file getattr; audit2allow -R #============= xdm_t ============== allow xdm_t tmp_t:sock_file getattr;
THis looks like a labeling problem. Those sockets should have been labeled xdm_tmp_t since I believe they are created by gdm? Could you delete the directory and reboot to see if the problem goes away. Might have been an install problem. How did you install this machine?
(In reply to comment #1) > THis looks like a labeling problem. Those sockets should have been labeled > xdm_tmp_t since I believe they are created by gdm? > > Could you delete the directory and reboot to see if the problem goes away. > > Might have been an install problem. How did you install this machine? There are several sockets labeled tmp_t in /tmp/at-spi2, including the one reported here. I did a clean install with the F15-Alpha net installer CD on Mar 29. Will report back after delete and reboot. [joeblow@fir at-spi2]$ ls --lcontext | grep ':tmp' srwxrwxrwx. 1 system_u:object_r:tmp_t:s0 gdm gdm 0 Mar 31 12:23 socket-1280-1684723479 srwxrwxrwx. 1 system_u:object_r:tmp_t:s0 gdm gdm 0 Mar 31 11:36 socket-1289-1009093448 srwxrwxrwx. 1 system_u:object_r:tmp_t:s0 gdm gdm 0 Mar 31 11:36 socket-1310-511702305 srwxrwxrwx. 1 system_u:object_r:tmp_t:s0 gdm gdm 0 Mar 31 12:23 socket-1380-1804289383 srwxrwxrwx. 1 system_u:object_r:tmp_t:s0 gdm gdm 0 Mar 31 11:36 socket-1383-1804289383 srwxrwxrwx. 1 system_u:object_r:tmp_t:s0 gdm gdm 0 Mar 31 11:36 socket-1385-1804289383 srwxrwxrwx. 1 system_u:object_r:tmp_t:s0 gdm gdm 0 Mar 31 11:36 socket-1386-1804289383 srwxrwxrwx. 1 system_u:object_r:tmp_t:s0 gdm gdm 0 Mar 31 11:36 socket-1387-1804289383 srwxrwxrwx. 1 system_u:object_r:tmp_t:s0 gdm gdm 0 Mar 31 11:36 socket-1388-1804289383 srwxrwxrwx. 1 system_u:object_r:tmp_t:s0 gdm gdm 0 Mar 31 11:36 socket-1389-1804289383 srwxrwxrwx. 1 system_u:object_r:tmp_t:s0 gdm gdm 0 Mar 31 11:36 socket-1435-1804289383 [joeblow@fir at-spi2]$
Yes I think this is installer related. These files had bad labels on it, and gdm/gnome-power-manager was trolling around in this directory and hit one, generating the AVC, The AVC could be ignored, since it would not block anything. This is why I always use tmpfs for /tmp. I want a clean /tmp on reboot.
After removing /tmp/at-spi2/ and rebooting, all the sockets are labeled xdm_tmp_t. There are no new avcs (per setroubleshoot). I can attach any log files, if needed. [joeblow@fir at-spi2]$ ls --lcontext -a total 8 drwxrwxrwt. 2 system_u:object_r:xdm_tmp_t:s0 gdm gdm 4096 Apr 1 10:17 . drwxrwxrwt. 16 system_u:object_r:tmp_t:s0 root root 4096 Apr 1 10:19 .. srwxrwxrwx. 1 system_u:object_r:xdm_tmp_t:s0 gdm gdm 0 Apr 1 10:17 socket-1351-2013295873 srwxrwxrwx. 1 system_u:object_r:xdm_tmp_t:s0 gdm gdm 0 Apr 1 10:17 socket-1360-511702305 srwxrwxrwx. 1 system_u:object_r:xdm_tmp_t:s0 gdm gdm 0 Apr 1 10:17 socket-1414-1804289383 srwxrwxrwx. 1 system_u:object_r:xdm_tmp_t:s0 gdm gdm 0 Apr 1 10:17 socket-1424-1804289383 srwxrwxrwx. 1 system_u:object_r:xdm_tmp_t:s0 gdm gdm 0 Apr 1 10:17 socket-1427-1804289383 srwxrwxrwx. 1 system_u:object_r:xdm_tmp_t:s0 gdm gdm 0 Apr 1 10:17 socket-1428-1804289383 srwxrwxrwx. 1 system_u:object_r:xdm_tmp_t:s0 gdm gdm 0 Apr 1 10:17 socket-1430-1804289383 srwxrwxrwx. 1 system_u:object_r:xdm_tmp_t:s0 gdm gdm 0 Apr 1 10:17 socket-1432-1804289383 srwxrwxrwx. 1 system_u:object_r:xdm_tmp_t:s0 gdm gdm 0 Apr 1 10:17 socket-1486-1804289383 [joeblow@fir at-spi2]$
No that is the way it is supposed to work. I think if you went back to your livecd and looked at the labels of that directory, they were wrong, or the installer created them with the wrong label.
I think the livecd is installing these files in /tmp?
I did a clean Live CD install and the sockets in /tmp/at-spi2/ are all labeled xdm_tmp_t. Reported in Bug 689143, Comment 10. Could the mislabeling somehow have occurred while the kernel was booted with selinux=0. I was doing that to work around boot hangs related to selinux/systemd integration?
(In reply to comment #7) > I did a clean Live CD install and the sockets in /tmp/at-spi2/ are all labeled > xdm_tmp_t. Reported in Bug 689143, Comment 10. > > Could the mislabeling somehow have occurred while the kernel was booted with > selinux=0. I was doing that to work around boot hangs related to > selinux/systemd integration? Bingo! I reproduced the mislabeling: 1. With selinux enabled, verify the sockets in /tmp/at-spi2/ are labeled xdm_tmp_t. 2. Boot with selinux=0 on the kernel command line and log in. Verify there are new sockets in /tmp/at-spi2/ with no labels (ls -lZ shows a "?".) 3. Reboot without selinux=0 and wait for relabeling to complete. 4. Log in. There are nine sockets in /tmp/at-spi2/ labeled tmp_t. selinux-policy-3.9.16-15
Created attachment 492686 [details] ls -alZ --full-time /tmp/at-spi2/
I will change the relabel to remove these sockets.
Fixed in policycoreutils-2.0.85-32.fc15