type=AVC msg=audit(1302788046.768:5309): avc: denied { unix_read unix_write
} for pid=6009 comm="mplayer" key=5678293
scontext=abc:user_r:user_t:s0:c0.c255-s0:c0.c511
tcontext=abc:user_r:mozilla_t:s0:c0.c255-s0:c0.c511 tclass=sem
In Debian we have a policy based on the 20100524 release. The above is the
result of trying to run mplayer after doing something in a web browser that
uses sound (Youtube on Chromium in this case).
Apart from allowing mozilla_t and user_t to access each other's semaphores,
rewriting the sound libraries, and using ipcrm, how can we solve this?
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On 4/14/2011 10:15 AM, Russell Coker wrote:
> type=AVC msg=audit(1302788046.768:5309): avc: denied { unix_read unix_write
> } for pid=6009 comm="mplayer" key=5678293
> scontext=abc:user_r:user_t:s0:c0.c255-s0:c0.c511
> tcontext=abc:user_r:mozilla_t:s0:c0.c255-s0:c0.c511 tclass=sem
>
> In Debian we have a policy based on the 20100524 release. The above is the
> result of trying to run mplayer after doing something in a web browser that
> uses sound (Youtube on Chromium in this case).
>
> Apart from allowing mozilla_t and user_t to access each other's semaphores,
> rewriting the sound libraries, and using ipcrm, how can we solve this?
I don't see any options beyond what you said. I assume mplayer fails
due to this denial? If so, I'm not sure I see what the problem with
allowing it is. Of course I'd rather not, but its not as bad as if the
access were the other way around. User_t already has to interact with
mozilla_t.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com