Firejail: Slack profile does not allow to use microphone

Created on 6 Jul 2018  路  9Comments  路  Source: netblue30/firejail

The problem

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.

Steps to reproduce

  1. Start Slack with Firejail.
  2. Open a direct message to a non-bot participant.
  3. Click on the telephone icon to start a call.

Environment

Slack version: 3.2.1 (64 bit)
Firejail version: 0.9.54
Linux kernel: 4.17.3

information

Most helpful comment

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

All 9 comments

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

Was this page helpful?
0 / 5 - 0 ratings