When Slack is started in Firejail sandbox, I can't get microphone working. The application says no sound comes from the mic. However the speakers are working as I can hear the other party.
If I run Slack without the sandboxing it works well.
Slack version: 3.2.1 (64 bit)
Firejail version: 0.9.54
Linux kernel: 4.17.3
Can you try if it works with one of these?
firejail --ignore=private-dev slack
firejail --ignore=whitelist slack
firejail --noblacklist=/var slack
Just some wild guesses.
Otherwise you could go to /etc/firejail/slack.profile, comment out all options (add a # in front of each line), and then uncomment line after line until you find the one that stops the microphone from working.
@smitsohu The last one (firejail --noblacklist=/var slack) solved the issue. Thanks for the hint.
I'm wondering if it's Linux distro dependent. In that case I would add this exception to firejail.local file. Otherwise it would be nice to add it to the main firejail.profile file for everyone's benefit.
Maybe we can replace the blacklist /var with the less restrictive whitelist /etc/firejail/whitelist-var-common.inc. Would that work for you?
If you are interested in hunting it down further, you can also run in one terminal sudo journalctl -fand in another firejail --tracelog slack. Then all blacklist violations should get logged in the first terminal.
I would help to track it down, but Slack does not start when I add the --tracelog switch. At least the application window is not showed up. Any idea why?
firejail --tracelog slack
Reading profile /etc/firejail/slack.profile
Reading profile /etc/firejail/slack.local
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-interpreters.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/whitelist-common.inc
Parent pid 25675, child pid 25676
Warning: skipping crypto-policies for private /etc
Private /etc installed in 30.36 ms
1 program installed in 0.60 ms
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Blacklist violations are logged to syslog
Child process initialized in 97.13 ms
As a rougher method you can use the following instead
firejail --allow-debuggers --profile=/etc/firejail/slack.profile strace -fv -o test.log /usr/bin/slack
grep "ENOENT" -v test.log | grep "/var" > var.txt
#open var.txt and try to find anything audio related
but I agree with @smitsohu, it should be safe to replace that line with whitelist-var-common.inc instead
@smitsohu, @SkewedZeppelin If I replace blacklist /var with whitelist /etc/firejail/whitelist-var-common.inc, Slack couldn't connect to the Internet.
Secondly strace revealed only some files in /var/cache/ directory which is not relevant. I also tried to run sudo lsof +D /var during the audio call (Slack wasn't sandboxed this time of course), but again no file was kept open by Slack processes.
@elvetemedve enoent might not be the best thing to search, can you skim the output of just the following?
grep "/var' test.log
As for not having Internet when using whitelist-var-common.inc, are you using systemd-resolved?
@elvetemedve I suspect there may be something in /var/run/ (probably the pulse files - on my system, they're in /var/run/user/1000/pulse/) which is necessary for this to work.
Interesting, I just tried firejail --blacklist=/var and parecord within it to see if pulseaudio was affected by the blacklisted /var, and it seems it wasn't - parecord worked just fine both outside and inside the jail. I will play around to see if a combination of options will cause pulseaudio to choke.
@elvetemedve Thanks for the bug report
Most helpful comment
As a rougher method you can use the following instead
but I agree with @smitsohu, it should be safe to replace that line with whitelist-var-common.inc instead