The following was filed automatically by setroubleshoot: Summary: SELinux is preventing /usr/bin/mutter "execmem" access on <Unknown>. Detailed Description: SELinux denied access requested by mutter. The current boolean settings do not allow this access. If you have not setup mutter to require this access this may signal an intrusion attempt. If you do intend this access you need to change the booleans on this system to allow the access. Allowing Access: One of the following booleans is set incorrectly: allow_execstack, allow_execmem Fix Command: Choose one of the following to allow access: Allow unconfined executables to make their stack executable. This should never, ever be necessary. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla") # setsebool -P allow_execstack 1 Allow unconfined executables to map a memory region as both executable and writable, this is dangerous and the executable should be reported in bugzilla") # setsebool -P allow_execmem 1 Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Objects None [ process ] Source mutter Source Path /usr/bin/mutter Port <Unknown> Host (removed) Source RPM Packages mutter-2.27.5-1.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-12.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_boolean Host Name (removed) Platform Linux (removed) 2.6.31.1-56.fc12.i686.PAE #1 SMP Tue Sep 29 16:16:16 EDT 2009 i686 i686 Alert Count 4 First Seen Tue 06 Oct 2009 08:57:21 PM BST Last Seen Tue 06 Oct 2009 08:57:21 PM BST Local ID 42c24883-5e51-416c-9ba4-88aece42dbc2 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1254859041.610:40): avc: denied { execmem } for pid=2604 comm="mutter" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process node=(removed) type=SYSCALL msg=audit(1254859041.610:40): arch=40000003 syscall=192 success=no exit=-13 a0=0 a1=2000 a2=7 a3=22 items=0 ppid=2599 pid=2604 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=1 comm="mutter" exe="/usr/bin/mutter" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) Hash String generated from selinux-policy-3.6.32-12.fc12,catchall_boolean,mutter,unconfined_t,unconfined_t,process,execmem audit2allow suggests: #============= unconfined_t ============== allow unconfined_t self:process execmem;
chcon -t execmem_exec_t /usr/bin/mutter will fix this. Not sure if mutter really needs this access though. or if it is a bug in the implementation.
There's no need for these bugs to be open against every app that uses GL. I can: - Reassign to setroubleshoot if setroubleshoot needs to check for nvidia binary drivers before reporting bugs - Can reassign to Mesa if this is a problem with Mesa
(If there's actually some magic goo that needs to be in the spec file for GL using apps, please let me know what it is. It also needs to be somewhere in the Fedora packaging docs.)
Owen I have no idea what uses nvidia. I have this blowing up on my machine which does not use nvidia. So I think that there is something else going on with mutter. execmem means execmem There are two situations when this error can appear: * The program maps anonymous memory with mmap with PROT_EXEC. Note that because anonymous memory is zero'd out by the system it makes not much sense to not have it writable as well. * The program maps a file with MAP_PRIVATE and both PROT_WRITE and PROT_EXEC. If the program really needs this behavior there is no really easy way out. One possibility is to create an anonymous file (just unlink it after creation), size the file using ftrunctate, and then map the file in two places. In one place map it with MAP_SHARED and write permission but without execution. For the second mapping use execution permissions but no write permissions. This might be a bit confusing at first but can be handled. The program must be adjusted to write to one location and expect to execute code in another one. This is reasonably safe in case the two mappings are allowed to be randomied. The example code in the next section illustrates how this should work. In the case of an anonymous mapping the best thing to do is to explicitly copy the file into an anonymous file and then proceed as described in the previous paragraph. Do you know if this is the situation with mutter?
There's no "Mutter" situation. Mutter is just a normal OpenGL app. Adding Adam Jackson to the Cc:. I have no idea what Mesa might or might not be doing that would require execmem. (I was thinking this was related to nVidia based on your comments on the identical bug against desktop-effects)
I cannot reproduce this issue in my setup. Mutter does not need execmem here. It would be nice to give /usr/bin/mutter type bin_t again if possible. I am using Intel Graphics.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
It's almost certainly the spidermonkey JIT being pulled in from gnome-shell, not nvidia.
...meaning that whatever solution was taken for firefox needs to be taken for gnome-shell as well. This is complicated by the fact that gnome-shell is actually a plugin for mutter, but I don't think we can sanely apply the policy somehow just to the combination so the fix will be need to done for mutter.
I am putting this label into Rawhide. /usr/bin/mutter -- gen_context(system_u:object_r:execmem_exec_t,s0) I will see what happens with this change.
So is this still an issue or is it fixed?
Should be fixed in the current release.