This is a continuation of bug 6993. It seems like there are more things broken by the new lockdown of Firefox, specifically audio. A quick glance at the SELinux logs suggest the issue is access to the PulseAudio cookie.
I experimented a bit and identified the key differences between ThinLinc and a local login: 1. a local login gets the auth cookie via X11, not from disk. We would need to include module-x11-publish to do the same, but it might create requirements on a modern libX11 since it uses the xcb API 2. the pulseaudio socket is located under /var/run, which it is allowed to use (it is tagged usr_tmp_t)
Fixing the above is not trivial, and this is only a temporary problem in Firefox that will be resolved once the next ESR is out, so let's see if we can do something more minimal by tweaking our SELinux rules.
Found some minimal rules to get things up an running. Tester should verify that audio in Firefox on RHEL 7 now works out of box, and that there isn't any AVC lines in audit.log
No release notes needed as bug 6993 prevented users from reaching this bug.
I was unable to reproduce this on CentOS 7/tl01.lab.cendio.se with Firefox 52.2, 52.3, nor 52.4. Tested with thinlinc 4.8.0post-5572, built on Wed 27 Sep 2017 04:15:23.
(In reply to comment #6) > I was unable to reproduce this on CentOS 7/tl01.lab.cendio.se with Firefox > 52.2, 52.3, nor 52.4. > > Tested with thinlinc 4.8.0post-5572, built on Wed 27 Sep 2017 04:15:23. I was able to reproduce on a RHEL7 system with 4.8.0post-5558. Maybe tl01.lab had been tampered with, patched or used as a development server? Trying to play a music video through Youtube with Firefox on build 5558 resulted in a warning bar with a hilariously poor translation of what I suspect said "In order to play audio you need the PulseAudio software installed". After upgrading to build 5578 and starting a new session, I could play audio without warning messages. Looks fine to me.