Bug 737790

What exactly are you seeing? What AVC? The policy should work.

(In reply to comment #2)
> What exactly are you seeing? What AVC? The policy should work.

The problem is:
I installed a RHEL6.2 guest and load virtio serial driver, qxl driver and spice vdagent service inside guest.
But on the guest login screen, the mouse will be captured by the guest. After login to guest desktop, it can move out from guest freely.

Maybe I cloned a wrong bug, sorry for make the confusion and please correct me for that.

Additional info based on Comment 3.
I edit /etc/sysconfig/selinux in the vm and set "SELINUX=permissive" there and then reboot. After that the mouse should work correctly on the login screen.

(In reply to comment #4)
> Additional info based on Comment 3.
> I edit /etc/sysconfig/selinux in the vm and set "SELINUX=permissive" there and
> then reboot. After that the mouse should work correctly on the login screen.

Right, I deliberately wrote should there, so the question is, does it work on the login screen after making that change?

Because if it does, then there still is a selinux issue, but if it doesn't then there is something else amiss.

Hi, Hans
After modify the /det/sysconfig/selinux file and reboot, it works well on the login screen and mouse will not be captured any more.

Ok, what avc are you getting?

# ausearch -m avc -ts today

(In reply to comment #7)
> Ok, what avc are you getting?
> 
> # ausearch -m avc -ts today

Hi, Miroslav
[root@dhcp-66-83-73 ~]# ausearch -m avc -ts today
<no matches>

Ok, please boot in enforcing mode and execute the following steps

# setenforce 0
# semodule -DB

re-test it and

# ausearch -m avc -ts recent

(In reply to comment #9)
> Ok, please boot in enforcing mode and execute the following steps
> 
> # setenforce 0
> # semodule -DB
> 
> re-test it and
> 
> # ausearch -m avc -ts recent

70880-time->Wed Sep 14 10:33:26 2011
70911:type=SYSCALL msg=audit(1316010806.700:196): arch=c000003e syscall=4 success=no exit=-13 a0=406068 a1=7fff6f48e2e0 a2=7fff6f48e2e0 a3=7fff6f48dfb0 items=0 ppid=2652 pid=2656 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 tty=(none) ses=4294967295 comm="spice-vdagent" exe="/usr/bin/spice-vdagent" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
71295:type=AVC msg=audit(1316010806.700:196): avc:  denied  { getattr } for  pid=2656 comm="spice-vdagent" path="/dev/vport0p2" dev=devtmpfs ino=9980 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virtio_device_t:s0 tclass=chr_file

The latest spice-vdagent had to change its behaviour, I downgraded it to spice-vdagent-0.6.3-8.el6 version (the one we tested and tuned selinux policy last time) and the problem does not occur there.

(In reply to comment #11)
> The latest spice-vdagent had to change its behaviour, I downgraded it to
> spice-vdagent-0.6.3-8.el6 version (the one we tested and tuned selinux policy
> last time) and the problem does not occur there.

Right, the fix for bug 681797 makes the per user (and gdm) xsession agent process
retry connecting to the system level agentd process, to avoid it doing this
indefinitely on systems which don't have the agent channel, it now also does
a stat call on /dev/virtio-ports/com.redhat.spice.0 (which is a symlink to a
/dev/vport#p#) to check that the system is configured with the agent channel.

Seeing the AVC I believe this change is where this new AVC comes from.

Note it does not need actual access to the device, it just needs to be able to stat it.

OK.

Marian or Qunfang,
if you execute

# grep virtio /var/log/audit/audit.log |audit2allow -M myvdagent
# semodule -i myvdagent.pp


does it work then?

(In reply to comment #13)
> OK.
> 
> Marian or Qunfang,
> if you execute
> 
> # grep virtio /var/log/audit/audit.log |audit2allow -M myvdagent
> # semodule -i myvdagent.pp
> 
> 
> does it work then?

Yes

Great. Thanks.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1511.html