SELinux is preventing /usr/bin/xauth from 'create' accesses on the shared memory Unknown. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that xauth should be allowed create access on the Unknown shm 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 xauth /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 Target Context unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 Target Objects Unknown [ shm ] Source xauth Source Path /usr/bin/xauth Port <未知> Host (removed) Source RPM Packages xorg-x11-xauth-1.0.2-9.fc15 Target RPM Packages Policy RPM selinux-policy-3.9.16-24.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.38.6-27.fc15.x86_64 #1 SMP Sun May 15 17:23:28 UTC 2011 x86_64 x86_64 Alert Count 1 First Seen 2011年05月23日 星期一 01时44分20秒 Last Seen 2011年05月23日 星期一 01时44分20秒 Local ID 63261231-c92e-42f7-aff7-2f0ea99da66a Raw Audit Messages type=AVC msg=audit(1306086260.997:96): avc: denied { create } for pid=7654 comm="xauth" key=0 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tclass=shm type=SYSCALL msg=audit(1306086260.997:96): arch=x86_64 syscall=shmget success=no exit=EACCES a0=0 a1=20b66 a2=380 a3=7fff69d11b60 items=0 ppid=7653 pid=7654 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts3 ses=1 comm=xauth exe=/usr/bin/xauth subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) Hash: xauth,xauth_t,xauth_t,shm,create audit2allow #============= xauth_t ============== allow xauth_t self:shm create; audit2allow -R #============= xauth_t ============== allow xauth_t self:shm create;
If you execute # semanage permissive -a xauth_t ("semanage permissive -d xauth_t" is opposite command) and re-test, what AVC msgs are you getting? And is it working then?
(In reply to comment #1) > If you execute > > # semanage permissive -a xauth_t ("semanage permissive -d xauth_t" is opposite > command) > > and re-test, what AVC msgs are you getting? And is it working then? I just use optimus with vgl << VirtualGL and 'optirun64 glxglears' and try other run with optirun64 ... maybe it was not bug,,
I did not know that xauthority ever used shared memory, but I see no reason to block this. Fixed in selinux-policy-3.9.16-25.fc15
(In reply to comment #3) > I did not know that xauthority ever used shared memory, but I see no reason to > block this. > > Fixed in selinux-policy-3.9.16-25.fc15 I --enablerepo=updates-testing check-update,but can not find it
Will available from koji today.
selinux-policy-3.9.16-26.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-26.fc15
Package selinux-policy-3.9.16-26.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.9.16-26.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-26.fc15 then log in and leave karma (feedback).
selinux-policy-3.9.16-26.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.