Bug 692905
Summary: | SELinux is preventing /usr/bin/gnome-power-manager from 'getattr' accesses on the sock_file /tmp/at-spi2/socket-1385-1804289383. | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Steve Tyler <stephent98> | ||||
Component: | policycoreutils | Assignee: | Daniel Walsh <dwalsh> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 15 | CC: | dcantrell, dwalsh, mgrepl | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | setroubleshoot_trace_hash:0e84e73165861a0c94238de45da96e803c0da64d0ecad9df6a070d66eddf63f0 | ||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2011-05-26 14:09:51 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Steve Tyler
2011-04-01 15:11:32 UTC
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 |