Perhaps other users have already run into this problem with Firefox ESR and Pulse Audio on Linux and solved it, but I am posting this here in case it might be helpful.
Although most software with audio output via Pulse on Linux works nicely in a chroot environment, Firefox (ESR) doesn't, even the pre-Quantum versions: No sound comes out! Apparently Firefox isn't satisfied with Pulse Audio's socket at "/run/pulse/native", even though I carefully made sure it was part of the chroot environment and had the chroot target user in the pulse-access group. But it *does* work if the environment variable "PULSE_SERVER=/run/pulse/native" is made available in the chroot environment. This is strange: although PULSE_SERVER is not available when SU-ing to the user in question, Firefox's sound works OK. I spent maybe a day reading the Firefox source code concerning audio (i.e., deep in the guts of the Cubeb code et al), but couldn't find exactly how FF connected to the socket, which apparently is used by Pulse to set up a shared "memfd" which is passed to the audio client. The FD is then *deleted* by both sides to make it inaccessible to other processes (some clever Unix FS trickery!). I also read some Pulse code, but that of course had no FF specific info. The Pulse and FF online docs aren't very helpful in this area, as this an obscure issue, and mainly they tell you things like "how to install Pulse" etc. (I did find a similar problem in some old Firejail posts, but no solution was indicated.) Luckily, in the course of searching online, I stumbled across the *existence* of the PULSE_SERVER environment variable, which I had never seen before, even in the online Pulse docs I read. So I tried adding it (with the obvious value) to the chroot environment et voila, it worked! Background -- why I have long used chroot for Firefox. The new versions of Firefox now have a "sandbox" which should improve security against bugs in various plugins etc., but older versions didn't. Furthermore, neither the older versions of FF nor the newer ones have any builtin way of totally hiding files or directories from Firefox beyond the limited capability of file permissions. Thus a minimum level of security and *privacy* would require at least running Firefox as a different user than the an individual with access to personal and business files. However, merely employing a separate user id doesn't hide the existence of other users, mounted disks or network file servers: using chroot does. Given the continual discovery of security flaws in Firefox (and other complex software), chroot provides an additional layer of security that is useful. This is especially the case given the increasing use of Javascript (for which I have long used NoScript) and the rise of HTTPS (which makes virus scanning much less possible). P.S. Although facilities like cgroups and namespaces might be better in the long run, I am not about to remove the protection afforded now by chroot while trying to get these mechanisms working. _______________________________________________ Enterprise mailing list Enterprise@mozilla.org https://mail.mozilla.org/listinfo/enterprise To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise or send an email to enterprise-requ...@mozilla.org with a subject of "unsubscribe"
