Bug 706749

Summary: SELinux is preventing /usr/bin/xauth from 'create' accesses on the shared memory Unknown.
Product: [Fedora] Fedora Reporter: cyrushmh <cyrusyzgtt>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 15CC: dominick.grift, dwalsh, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:9dc3cb5e7741198caed7f6d10176dec19dd5e6583b3e7becb6e34a07e0e96678
Fixed In Version: selinux-policy-3.9.16-26.fc15 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-03 05:30:09 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:

Description cyrushmh 2011-05-22 17:46:39 UTC
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;

Comment 1 Miroslav Grepl 2011-05-23 08:04:33 UTC
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?

Comment 2 cyrushmh 2011-05-23 19:10:19 UTC
(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,,

Comment 3 Daniel Walsh 2011-05-23 19:51:37 UTC
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

Comment 4 cyrushmh 2011-05-24 00:21:21 UTC
(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

Comment 5 Miroslav Grepl 2011-05-24 06:04:37 UTC
Will available from koji today.

Comment 6 Fedora Update System 2011-05-27 16:56:10 UTC
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

Comment 7 Fedora Update System 2011-05-28 23:58:12 UTC
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).

Comment 8 Fedora Update System 2011-06-03 05:29:24 UTC
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.