zoom profile: can't access webcam

[tornaria]

After #3518, zoom cannot access webcam via /dev/video*.

Bug and expected behavior

$ firejail --quiet --profile=/etc/firejail/zoom.profile id
uid=1000 gid=1000 groups=1000
$ firejail --quiet --profile=/etc/firejail/zoom.profile ls -l /dev/video*
crw-rw---- 1 65534 65534 81, 0 Oct 30 17:12 /dev/video0
crw-rw---- 1 65534 65534 81, 1 Oct 30 17:12 /dev/video1

It turns out the user doesn't have access to the devices /dev/video* because it lacks the group video (note that outside firejail, the user does have access to the group video)

Workaround

In zoom.profile, if I comment out nogroup and I add group to the private-etc whitelist, then it works:

$ firejail --quiet --profile=/etc/firejail/zoom.profile id
uid=1000 gid=1000(tornaria) groups=1000(tornaria),12(audio),13(video)

since now the user is in group video, it has access to the devices /dev/video* and the webcam works.

Extra comments

a. I couldn't find a way to override nogroups in my local profile. Is there any way?

b. audio and video groups are kept only if /etc/group is whitelisted in private-etc, presumably because the identification of the groups is done by name inside firejail. Would it make sense to use the group names outside of firejail so that /etc/group is not needed?

c. Would it make sense for nogroups to also except special groups like audio and video?

d. Is there another workaround that I'm not seeing?

[glitsj16]

Thank you for reporting this. To me this sounds like a bug and we should update the zoom profile accordingly. A video conferencing app like zoom should provide necessary functionality without the user having to rely on a local override.

a. I couldn't find a way to override nogroups in my local profile. Is there any way?

ignore nogroups
private-etc group

b. [...] Would it make sense to use the group names outside of firejail so that /etc/group is not needed?

I don't see how that would work. We have several profiles that don't have the nogroups option. If it guarantees expected functionality it is OK to leave it out.

c. Would it make sense for nogroups to also except special groups like audio and video?

Technically it should be possible, one can always code in such exceptions. But in this case I don't see the benefit of doing so. No means no, and not 'no but yes for x & y'. It would only cause confusion IMHO. Hence I'm marking this as a bug and will keep it open to see what other responses we get on this issue.

[rusty-snake]

Are you on a system w/o systemd?

c: nogroups means nogroups, IMHO we should not change this. Anyway there is #2042 (and #3303).

[glitsj16]

@tornaria I went ahead and made the needed changes in git. Please feel free to reopen if you experience the same issue again after updating firejail.

[rusty-snake]

@glitsj16 @tornaria nogroups breaks commonly unprivileged access inside /dev on non-systemd system. If that's the case, we should add a note so users can comment/uncomment it easily because the know when it is save.

[glitsj16]

@rusty-snake Good point, let's reopen this and wait for @tornaria to chime in so we can add such a note.

[tornaria]

@glitsj16 @rusty-snake
Sorry for the delay. Indeed, I use void linux which does not use systemd.

[glitsj16]

@tornaria That's alright. I made a PR to re-enable 'nogroups' and added a comment how users on non-systemd systems need to deal with this. Thanks for getting back to us, I think we can close this once the PR gets merged.

[glitsj16]

@tornaria PR is in. Feel free to reopen if you experience any oddness with zoom.