Hide Forgot
SELinux is preventing /usr/libexec/gnome-session-check-accelerated-helper from 'execute' accesses on the file /tmp/glPkUWIO (deleted). ***** Plugin catchall (100. confidence) suggests *************************** If you believe that gnome-session-check-accelerated-helper should be allowed execute access on the glPkUWIO (deleted) 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-session-c /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:xdm_tmp_t:s0 Target Objects /tmp/glPkUWIO (deleted) [ file ] Source gnome-session-c Source Path /usr/libexec/gnome-session-check-accelerated- helper Port <Unknown> Host (removed) Source RPM Packages gnome-session-3.0.1-2.fc15 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.x86_64 #1 SMP Mon Jun 13 19:49:05 UTC 2011 x86_64 x86_64 Alert Count 3 First Seen Št 30. jún 2011, 14:22:23 CEST Last Seen Št 30. jún 2011, 15:09:45 CEST Local ID 3dcb16da-acaa-42c5-8f1d-5eabe390c0e6 Raw Audit Messages type=AVC msg=audit(1309439385.89:41): avc: denied { execute } for pid=10280 comm="gnome-session-c" path=2F746D702F676C506B5557494F202864656C6574656429 dev=dm-0 ino=925469 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xdm_tmp_t:s0 tclass=file type=SYSCALL msg=audit(1309439385.89:41): arch=x86_64 syscall=mmap success=no exit=EACCES a0=0 a1=2000 a2=5 a3=1 items=0 ppid=10269 pid=10280 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 tty=(none) ses=4294967295 comm=gnome-session-c exe=/usr/libexec/gnome-session-check-accelerated-helper subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) Hash: gnome-session-c,xdm_t,xdm_tmp_t,file,execute audit2allow #============= xdm_t ============== allow xdm_t xdm_tmp_t:file execute; audit2allow -R #============= xdm_t ============== allow xdm_t xdm_tmp_t:file execute;
Any idea what's going on?
It is probably doing an access_check. gdm is running a whole gnome-session, but I think we can dontaudit this and everything will work fine.
edo, does everything work for you?
I'm seeing this as well. Happened after I ran SELinux Troubleshooter and tried to fix a similar error with a target of nvidiactl (instead of the /tmp file noted here). Tried to implement the suggested fix which again was similar. Became superuser and moved to /etc/selinux/targeted/modules/active/modules/ grep gnome-session-c /var/log/audit/audit.log | audit2allow -M nvidiactlpol semodule -i nvidiactlpol.pp After the next reboot it would not go into Gnome3, but only into the Gnome2 backup mode. Checked SELinux Troubleshooter and saw this new error with the /tmp file instead of the original error with nvidiactl. Reinstalled selinux-policy and selinux-policy-targeted but still receive same error and it wouldn't boot into Gnome3. Set policy in /etc/selinux/config to permissive and rebooted. Went straight into Gnome3, no problem. Also tried to reinstall kmod-nvidia and xorg-x11-drv-nvidia and this problem remains.
Forgot to note, that although I was seeing the similar error with nvidiactl it was booting into Gnome3 no problem. Should have left it alone.
Looks like something was hosed up in the policy store. Resetting [per https://bugzilla.redhat.com/show_bug.cgi?id=518094] solved it by executing the following: setenforce 0 mv /etc/selinux/targeted /etc/selinux/targeted.old yum reinstall selinux-policy\* restorecon -R -v /etc/selinux setenforce 1 Now I am back to the original SELinux error. Which was: SELinux is preventing /usr/libexec/gnome-session-check-accelerated-helper from 'read, write' accesses on the chr_file nvidiactl Which is a CANTFIX. [per https://bugzilla.redhat.com/show_bug.cgi?id=694918] This is okay as boot continues successfully into Gnome3 despite the error. So, lesson learned is, DON'T run the SELinux Troubleshooter suggestion for bug 694918. I've read that there will be a new policy to help accommodate third party bad labels in Fedora 16. Hope this helps someone else.
Vander, what does # grep gnome-session-c /var/log/audit/audit.log on your machine.
Created attachment 515818 [details] Output of grep gnome-session-c... Attached a text file with the output as a lot of these are repeated over and over. Not sure how far back this goes so can't point directly to where I had it working again. Also, providing a smolt link... http://www.smolts.org/client/show/?uuid=pub_bc64c4a3-1078-4e9d-81f3-5e99d3ef44c6 Let me know if I can provide anything else.
Still present in selinux-policy-targeted-3.9.16-35.fc15 I have manually (from a non-gnome session) done restorecon on /dev/nvidia*, and they have the type xserver_misc_device_t. Then, when doing a gnome login, I don't get the previous complaint about gnome-session-check-accelerated-helper not being able to read and write those device files. Instead I get this complaint about it being unable to execute a file in /tmp. The precise name of the file is of course different, this is a typical mkstemp() pattern. But it starts the same, with /tmp/gl, and doing strings on /usr/lib64/nvidia/libGL.so.1 I do see that template: freddi$ strings - /usr/lib64/nvidia/libGL.so.1 | grep /tmp /tmp/glXXXXXX To figure out what it actually uses the file for, I ran gnome-session-check-accelerated-helper on the command line under ltrace and strace. Unless I'm mistaken, what it does is it creates an 8kB memory area that it maps in, but what it then uses it for is not so easy to find out. It does this in the function glXMakeCurrent() open("/tmp/gl175aRq", O_RDWR|O_CREAT|O_EXCL, 0600) = 9 unlink("/tmp/gl175aRq") = 0 ftruncate(9, 8192) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x7fe1b97b7000 mmap(NULL, 8192, PROT_READ|PROT_EXEC, MAP_SHARED|MAP_32BIT, 9, 0) = 0x408b8000 close(9) = 0 Obviously, this happens inside the proprietary Nvidia library. I guess we can't fix it. Does that mean the allow rule that setroubleshoot suggested should be included in the standard policy? Assuming this driver still is to be supported, that is, but I guess it is?
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping