[GH-ISSUE #4603] Feature Request: Logind conditional

gitea-mirror commented

2026-05-05 09:22:52 -06:00

Owner

Originally created by @crocket on GitHub (Oct 13, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4603

(e)udev attaches uaccess tag to devices.
systemd-logind and elogind grant logged-in users rights to devices with uaccess tag.
With logind, noroot and nogroups don't break device access.
Without logind, noroot or nogroups may break device access.

Some linux distributions like Void Linux and Gentoo Linux allow users to replace logind with other seat managers like seatd.

Describe the solution you'd like

To support all linux distributions and all seat managers without any manual user configuration, a logind conditional like ?SEAT-ACL is desirable. Then,

noroot
nogroups

can be replaced with

?SEAT-ACL: noroot
?SEAT-ACL: nogroups

Originally created by @crocket on GitHub (Oct 13, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/4603 ### Is your feature request related to a problem? Please describe. (e)udev attaches uaccess tag to devices. systemd-logind and elogind grant logged-in users rights to devices with uaccess tag. With logind, `noroot` and `nogroups` don't break device access. Without logind, `noroot` or `nogroups` may break device access. Some linux distributions like Void Linux and Gentoo Linux allow users to replace logind with other seat managers like seatd. ### Describe the solution you'd like To support all linux distributions and all seat managers without any manual user configuration, a logind conditional like `?SEAT-ACL` is desirable. Then, ``` noroot nogroups ``` can be replaced with ``` ?SEAT-ACL: noroot ?SEAT-ACL: nogroups ```

gitea-mirror

2026-05-05 09:22:52 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 09:22:55 -06:00

Author

Owner

@rusty-snake commented on GitHub (Oct 13, 2021):

?SEAT-ACL: noroot
?SEAT-ACL: nogroups

Would require maintaining that they are always behind a condition. I would prefer a more implicit solution.

Previous discussions: #4600, #4531, #4602
Related issues: #3711, #841, #3303, #2042

@rusty-snake commented on GitHub (Oct 13, 2021): > ?SEAT-ACL: noroot > ?SEAT-ACL: nogroups Would require maintaining that they are always behind a condition. I would prefer a more implicit solution. --- Previous discussions: #4600, #4531, #4602 Related issues: #3711, #841, #3303, #2042

gitea-mirror commented

2026-05-05 09:22:56 -06:00

Author

Owner

@crocket commented on GitHub (Oct 13, 2021):

noroot-if-seat-acl and nogroups-if-seat-acl?

Or, noroot and nogroups kick in only if seat-acl is present.

@crocket commented on GitHub (Oct 13, 2021): noroot-if-seat-acl and nogroups-if-seat-acl? Or, noroot and nogroups kick in only if seat-acl is present.

gitea-mirror commented

2026-05-05 09:22:57 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 13, 2021):

Quoting @crocket from #4600

There can be better ways to manage permission than noroot and nogroups. I read about a
discussion of fine-grained control over access to supplementary groups.

To me this sounds more useful than a conditional alone. And once facilities are in place, they could also be exposed in firejail.config, so that users, and maybe distributions, find it easier to adapt firejail to their setup.

Edit to clarify: I was referring to something like #2042

@smitsohu commented on GitHub (Oct 13, 2021): Quoting @crocket from #4600 > There can be better ways to manage permission than noroot and nogroups. I read about a discussion of fine-grained control over access to supplementary groups. To me this sounds more useful than a conditional alone. And once facilities are in place, they could also be exposed in `firejail.config`, so that users, and maybe distributions, find it easier to adapt firejail to their setup. Edit to clarify: I was referring to something like #2042

gitea-mirror commented

2026-05-05 09:22:58 -06:00

Author

Owner

@topimiettinen commented on GitHub (Oct 14, 2021):

@smitsohu Let's say fine-grained group control means something like groups.drop sudo (black/denylist) and groups.keep audio (white/allowlist). The case for local admin is clear, maybe also for distros, but how could we use them in upstream profiles? Maybe just commented out as examples?

@topimiettinen commented on GitHub (Oct 14, 2021): @smitsohu Let's say fine-grained group control means something like `groups.drop sudo` (black/denylist) and `groups.keep audio` (white/allowlist). The case for local admin is clear, maybe also for distros, but how could we use them in upstream profiles? Maybe just commented out as examples?

gitea-mirror commented

2026-05-05 09:22:59 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 14, 2021):

@topimiettinen Right. This kind of fine grained control (groups.drop) won't be very helpful for upstream profiles. I was thinking from the perspective of an administrator, but a more dynamic solution would be clearly better.

@smitsohu commented on GitHub (Oct 14, 2021): @topimiettinen Right. This kind of fine grained control (`groups.drop`) won't be very helpful for upstream profiles. I was thinking from the perspective of an administrator, but a more dynamic solution would be clearly better.

gitea-mirror commented

2026-05-05 09:23:00 -06:00

Author

Owner

@kmk3 commented on GitHub (Oct 15, 2021):

@topimiettinen commented on Oct 14:

@smitsohu Let's say fine-grained group control means something like
groups.drop sudo (black/denylist) and groups.keep audio
(white/allowlist). The case for local admin is clear, maybe also for distros,
but how could we use them in upstream profiles? Maybe just commented out as
examples?

@smitsohu commented on Oct 14:

@topimiettinen Right. This kind of fine grained control (groups.drop) won't
be very helpful for upstream profiles. I was thinking from the perspective of
an administrator, but a more dynamic solution would be clearly better.

Considering groups.keep being more desirable than ?SET_FACL, that there is
a working implementation of the former and assuming that the audio group (if
any) is called "audio" on basically every distro that has firejail (would have
to check this one):

If a program requires audio output (e.g.: mpv), would there be any downside in
replacing nogroups with e.g.: groups.keep audio in its profile?

On distros that default to systemd/pulseaudio, are new users added to an audio
group by default? If not, I think that @topimiettinen's multi-seat
concern would not apply, as the user would have to be deliberately added to
such a group. As in, I think that this responsibility would fall on the user
rather than on firejail (though we could document it of course).

Also, if there are more things needed to unblock (e.g.: specific device files)
other than the group, maybe there could be an include like the following:

allow-audio.inc:

ignore nogroups

# alsa
noblacklist /dev/snd/*

# sndio
noblacklist /dev/audio*
noblacklist /dev/midi*

groups.keep audio

That is, adding include allow-audio.inc to relevant profiles rather than
replacing nogroups with groups.keep audio on them.

Overriding the above (in e.g.: allow-audio.local) would also permit allowing
only specific devices rather than every audio device, which would be even more
granular than just groups.keep. Example:

ignore noblacklist /dev/audio*

noblacklist /dev/audio3

write-only /dev/audio3

Note: There is currently no write-only, but having something like the above
looks like it could also effectively fix the following issue:

#4565

And if someone would like to avoid allowing any groups at all, then something
like ignore include allow-audio.inc (or ignore ignore nogroups) could be
added to globals.local.

@kmk3 commented on GitHub (Oct 15, 2021): @topimiettinen commented [on Oct 14](https://github.com/netblue30/firejail/issues/4603#issuecomment-943695687): > @smitsohu Let's say fine-grained group control means something like > `groups.drop sudo` (black/denylist) and `groups.keep audio` > (white/allowlist). The case for local admin is clear, maybe also for distros, > but how could we use them in upstream profiles? Maybe just commented out as > examples? @smitsohu commented [on Oct 14](https://github.com/netblue30/firejail/issues/4603#issuecomment-943778799): > @topimiettinen Right. This kind of fine grained control (`groups.drop`) won't > be very helpful for upstream profiles. I was thinking from the perspective of > an administrator, but a more dynamic solution would be clearly better. Considering `groups.keep` being more desirable than `?SET_FACL`, that there is a working implementation of the former and assuming that the audio group (if any) is called "audio" on basically every distro that has firejail (would have to check this one): If a program requires audio output (e.g.: mpv), would there be any downside in replacing `nogroups` with e.g.: `groups.keep audio` in its profile? On distros that default to systemd/pulseaudio, are new users added to an audio group by default? If not, I think that @topimiettinen's [multi-seat concern][1] would not apply, as the user would have to be deliberately added to such a group. As in, I think that this responsibility would fall on the user rather than on firejail (though we could document it of course). Also, if there are more things needed to unblock (e.g.: specific device files) other than the group, maybe there could be an include like the following: allow-audio.inc: ```firejail ignore nogroups # alsa noblacklist /dev/snd/* # sndio noblacklist /dev/audio* noblacklist /dev/midi* groups.keep audio ``` That is, adding `include allow-audio.inc` to relevant profiles rather than replacing `nogroups` with `groups.keep audio` on them. Overriding the above (in e.g.: allow-audio.local) would also permit allowing only specific devices rather than every audio device, which would be even more granular than just `groups.keep`. Example: ```firejail ignore noblacklist /dev/audio* noblacklist /dev/audio3 write-only /dev/audio3 ``` Note: There is currently no `write-only`, but having something like the above looks like it could also effectively fix the following issue: * #4565 And if someone would like to avoid allowing any groups at all, then something like `ignore include allow-audio.inc` (or `ignore ignore nogroups`) could be added to globals.local. [1]: https://github.com/netblue30/firejail/pull/4600#issuecomment-939424472

gitea-mirror commented

2026-05-05 09:23:00 -06:00

Author

Owner

@crocket commented on GitHub (Oct 15, 2021):

It doesn't make much sense to put ignore nogroups in allow-audio.inc if allow-audio.inc is included in main profiles.

You should just remove nogroups.

Adding more stuff to counteract existing stuff is counterproductive. We should remove lines instead.

If we keep adding stuff without eliminating lines, we may end up with something like ignore ignore ignore nogroups

@crocket commented on GitHub (Oct 15, 2021): It doesn't make much sense to put `ignore nogroups` in allow-audio.inc if allow-audio.inc is included in main profiles. You should just remove `nogroups`. Adding more stuff to counteract existing stuff is counterproductive. We should remove lines instead. If we keep adding stuff without eliminating lines, we may end up with something like `ignore ignore ignore nogroups`

gitea-mirror commented

2026-05-05 09:23:01 -06:00

Author

Owner

@rusty-snake commented on GitHub (Oct 15, 2021):

If we keep adding stuff without eliminating lines, we may end up with something like ignore ignore ignore nogroups

ignore nogroups is enough.

What about nogroups <all|auto|none>?

nogroups all (and alias nogroups for backward compatibility) will drop all supplementary groups. (and noroot will not change groups #3303)
nogroups none will keep all groups (maybe we don't need this as it is the same as not using nogroups and just complicates things)

nogroups auto will autodetect which groups it should keep (whitelisting)

if !arg_nosound:
    drop_group("audio")
if !arg_novideo:
    drop_group("video")
if !arg_nodvd:
    drop_group("cdrom")
if !arg_noinput:
    drop_group("input")
if !arg_no3d: // /dev/dri/card0 has group video
    drop_group("render")
if !arg_noprinters:
    drop_group("lp")

in case other group names are used, we can provide mappings in firejail.config

@rusty-snake commented on GitHub (Oct 15, 2021): > If we keep adding stuff without eliminating lines, we may end up with something like `ignore ignore ignore nogroups` `ignore nogroups` is enough. ---- What about `nogroups <all|auto|none>`? - `nogroups all` (and alias `nogroups` for backward compatibility) will drop all supplementary groups. (and `noroot` will not change groups #3303) - `nogroups none` will keep all groups (maybe we don't need this as it is the same as not using `nogroups` and just complicates things) - `nogroups auto` will autodetect which groups it should keep (whitelisting) ```js if !arg_nosound: drop_group("audio") if !arg_novideo: drop_group("video") if !arg_nodvd: drop_group("cdrom") if !arg_noinput: drop_group("input") if !arg_no3d: // /dev/dri/card0 has group video drop_group("render") if !arg_noprinters: drop_group("lp") ``` in case other group names are used, we can provide mappings in firejail.config

gitea-mirror commented

2026-05-05 09:23:02 -06:00

Author

Owner

@crocket commented on GitHub (Oct 15, 2021):

I think I like nogroups (all) and nogroups auto. I also want noroot to not touch groups.

@crocket commented on GitHub (Oct 15, 2021): I think I like `nogroups (all)` and `nogroups auto`. I also want `noroot` to not touch groups.

gitea-mirror commented

2026-05-05 09:23:02 -06:00

Author

Owner

@topimiettinen commented on GitHub (Oct 15, 2021):

@topimiettinen commented on Oct 14:

@smitsohu Let's say fine-grained group control means something like
groups.drop sudo (black/denylist) and groups.keep audio
(white/allowlist). The case for local admin is clear, maybe also for distros,
but how could we use them in upstream profiles? Maybe just commented out as
examples?

@smitsohu commented on Oct 14:

@topimiettinen Right. This kind of fine grained control (groups.drop) won't
be very helpful for upstream profiles. I was thinking from the perspective of
an administrator, but a more dynamic solution would be clearly better.

Considering groups.keep being more desirable than ?SET_FACL, that there is a working implementation of the former and assuming that the audio group (if any) is called "audio" on basically every distro that has firejail (would have to check this one):

If a program requires audio output (e.g.: mpv), would there be any downside in replacing nogroups with e.g.: groups.keep audio in its profile?

The users would gain access to this GID, which they didn't have before. Then they could make setgid binaries to keep the rights after Firejail exits.

On distros that default to systemd/pulseaudio, are new users added to an audio group by default? If not, I think that @topimiettinen's multi-seat concern would not apply, as the user would have to be deliberately added to such a group. As in, I think that this responsibility would fall on the user rather than on firejail (though we could document it of course).

I don't think so. At least my user isn't a member in any audio or cdrom groups.

Also, if there are more things needed to unblock (e.g.: specific device files) other than the group, maybe there could be an include like the following:

allow-audio.inc:
ignore nogroups

# alsa
noblacklist /dev/snd/*

# sndio
noblacklist /dev/audio*
noblacklist /dev/midi*

groups.keep audio
That is, adding include allow-audio.inc to relevant profiles rather than replacing nogroups with groups.keep audio on them.

Overriding the above (in e.g.: allow-audio.local) would also permit allowing only specific devices rather than every audio device, which would be even more granular than just groups.keep. Example:
ignore noblacklist /dev/audio*

noblacklist /dev/audio3

write-only /dev/audio3
Note: There is currently no write-only, but having something like the above looks like it could also effectively fix the following issue:
* [audio input is not blocked in default.profile (contrary to video input) #4565](https://github.com/netblue30/firejail/issues/4565)
And if someone would like to avoid allowing any groups at all, then something like ignore include allow-audio.inc (or ignore ignore nogroups) could be added to globals.local.

Nice idea, though I don't think giving access is necessary for logind distros. In my setup, pulseaudio is started from systemd --user and it has access to /dev/snd/ directory, but the DE programs (for example Firefox) inherit the /dev tree from display-manager.service, which has no access to /dev/snd/ at all (PrivateDevices=yes but then BindReadOnlyPaths= for some devices, excluding /dev/snd). Still, sound works fine in the DE programs because they connect to pulseaudio instead of touching the devices directly. Firejailed pulseaudio would need the access of course.

@topimiettinen commented on GitHub (Oct 15, 2021): > @topimiettinen commented [on Oct 14](https://github.com/netblue30/firejail/issues/4603#issuecomment-943695687): > > > @smitsohu Let's say fine-grained group control means something like > > `groups.drop sudo` (black/denylist) and `groups.keep audio` > > (white/allowlist). The case for local admin is clear, maybe also for distros, > > but how could we use them in upstream profiles? Maybe just commented out as > > examples? > > @smitsohu commented [on Oct 14](https://github.com/netblue30/firejail/issues/4603#issuecomment-943778799): > > > @topimiettinen Right. This kind of fine grained control (`groups.drop`) won't > > be very helpful for upstream profiles. I was thinking from the perspective of > > an administrator, but a more dynamic solution would be clearly better. > > Considering `groups.keep` being more desirable than `?SET_FACL`, that there is a working implementation of the former and assuming that the audio group (if any) is called "audio" on basically every distro that has firejail (would have to check this one): > > If a program requires audio output (e.g.: mpv), would there be any downside in replacing `nogroups` with e.g.: `groups.keep audio` in its profile? The users would gain access to this GID, which they didn't have before. Then they could make setgid binaries to keep the rights after Firejail exits. > On distros that default to systemd/pulseaudio, are new users added to an audio group by default? If not, I think that @topimiettinen's [multi-seat concern](https://github.com/netblue30/firejail/pull/4600#issuecomment-939424472) would not apply, as the user would have to be deliberately added to such a group. As in, I think that this responsibility would fall on the user rather than on firejail (though we could document it of course). I don't think so. At least my user isn't a member in any audio or cdrom groups. > Also, if there are more things needed to unblock (e.g.: specific device files) other than the group, maybe there could be an include like the following: > > allow-audio.inc: > > ``` > ignore nogroups > > # alsa > noblacklist /dev/snd/* > > # sndio > noblacklist /dev/audio* > noblacklist /dev/midi* > > groups.keep audio > ``` > > That is, adding `include allow-audio.inc` to relevant profiles rather than replacing `nogroups` with `groups.keep audio` on them. > > Overriding the above (in e.g.: allow-audio.local) would also permit allowing only specific devices rather than every audio device, which would be even more granular than just `groups.keep`. Example: > > ``` > ignore noblacklist /dev/audio* > > noblacklist /dev/audio3 > > write-only /dev/audio3 > ``` > > Note: There is currently no `write-only`, but having something like the above looks like it could also effectively fix the following issue: > > * [audio input is not blocked in default.profile (contrary to video input) #4565](https://github.com/netblue30/firejail/issues/4565) > > > And if someone would like to avoid allowing any groups at all, then something like `ignore include allow-audio.inc` (or `ignore ignore nogroups`) could be added to globals.local. Nice idea, though I don't think giving access is necessary for logind distros. In my setup, pulseaudio is started from `systemd --user` and it has access to `/dev/snd/` directory, but the DE programs (for example Firefox) inherit the `/dev` tree from `display-manager.service`, which has no access to `/dev/snd/` at all (`PrivateDevices=yes` but then `BindReadOnlyPaths=` for some devices, excluding `/dev/snd`). Still, sound works fine in the DE programs because they connect to pulseaudio instead of touching the devices directly. Firejailed pulseaudio would need the access of course.

gitea-mirror commented

2026-05-05 09:23:03 -06:00

Author

Owner

@topimiettinen commented on GitHub (Oct 15, 2021):

If we keep adding stuff without eliminating lines, we may end up with something like ignore ignore ignore nogroups

ignore nogroups is enough.

What about nogroups <all|auto|none>?

* `nogroups all` (and alias `nogroups` for backward compatibility) will drop all supplementary groups. (and `noroot` will not change groups [noroot removes all user groups, nogroups redundant #3303](https://github.com/netblue30/firejail/issues/3303))

* `nogroups none` will keep all groups (maybe we don't need this as it is the same as not using `nogroups` and just complicates things)

* `nogroups auto` will autodetect which groups it should keep (whitelisting)
  ```js
  if !arg_nosound:
      drop_group("audio")
  if !arg_novideo:
      drop_group("video")
  if !arg_nodvd:
      drop_group("cdrom")
  if !arg_noinput:
      drop_group("input")
  if !arg_no3d: // /dev/dri/card0 has group video
      drop_group("render")
  if !arg_noprinters:
      drop_group("lp")
  ```

This could work well if also coupled with the logind check, so users on distros with logind would not get extra permissions but others would get at least some groups automatically when needed.

I think your auto concept is interesting more generally. Now there's a lot of heuristics going on in Firejail (to improve user friendliness) but it may be impossible to override them. But we could start introducing sort of auto (heuristics on) and manual modes (everything has to be specified explicitly, like bubblewrap) for each setting with heuristics now.

@topimiettinen commented on GitHub (Oct 15, 2021): > > If we keep adding stuff without eliminating lines, we may end up with something like `ignore ignore ignore nogroups` > > `ignore nogroups` is enough. > > What about `nogroups <all|auto|none>`? > > * `nogroups all` (and alias `nogroups` for backward compatibility) will drop all supplementary groups. (and `noroot` will not change groups [noroot removes all user groups, nogroups redundant #3303](https://github.com/netblue30/firejail/issues/3303)) > > * `nogroups none` will keep all groups (maybe we don't need this as it is the same as not using `nogroups` and just complicates things) > > * `nogroups auto` will autodetect which groups it should keep (whitelisting) > ```js > if !arg_nosound: > drop_group("audio") > if !arg_novideo: > drop_group("video") > if !arg_nodvd: > drop_group("cdrom") > if !arg_noinput: > drop_group("input") > if !arg_no3d: // /dev/dri/card0 has group video > drop_group("render") > if !arg_noprinters: > drop_group("lp") > ``` This could work well if also coupled with the logind check, so users on distros with logind would not get extra permissions but others would get at least some groups automatically when needed. I think your `auto` concept is interesting more generally. Now there's a lot of heuristics going on in Firejail (to improve user friendliness) but it may be impossible to override them. But we could start introducing sort of `auto` (heuristics on) and `manual` modes (everything has to be specified explicitly, like bubblewrap) for each setting with heuristics now.

gitea-mirror commented

2026-05-05 09:23:03 -06:00

Author

Owner

@crocket commented on GitHub (Oct 15, 2021):

The users would gain access to this GID, which they didn't have before. Then they could make setgid binaries to keep the rights after Firejail exits.

Are you personally using firejail in public multi-seat computers? Isn't seccomp going to disable setting setgid bit?

In single-user computers, your scenario doesn't make sense.

@crocket commented on GitHub (Oct 15, 2021): > The users would gain access to this GID, which they didn't have before. Then they could make setgid binaries to keep the rights after Firejail exits. Are you personally using firejail in public multi-seat computers? Isn't `seccomp` going to disable setting setgid bit? In single-user computers, your scenario doesn't make sense.

gitea-mirror commented

2026-05-05 09:23:04 -06:00

Author

Owner

@topimiettinen commented on GitHub (Oct 15, 2021):

The users would gain access to this GID, which they didn't have before. Then they could make setgid binaries to keep the rights after Firejail exits.

Are you personally using firejail in public multi-seat computers? Isn't seccomp going to disable setting setgid bit?

Firejail doesn't have a feature similar to systemd's RestrictSUIDSGID=yes.

In single-user computers, your scenario doesn't make sense.

The 'user' in the scenario could be also an attacker, who temporarily gains limited access using for example browser vulnerabilities or indirectly via an organization's shared network file system. We don't know well in advance what makes sense for all future attack scenarios and every little bit of extra security can help weaken the attacker's capabilities. There's no global switch 'security=on' which could block all possible attacks. Instead there are yet unknown weaknesses of various sizes which may lead to vulnerabilities and exploits, and attempts to make attackers' lives more difficult to counter the possibility of weaknesses.

@topimiettinen commented on GitHub (Oct 15, 2021): > > The users would gain access to this GID, which they didn't have before. Then they could make setgid binaries to keep the rights after Firejail exits. > > Are you personally using firejail in public multi-seat computers? Isn't `seccomp` going to disable setting setgid bit? Firejail doesn't have a feature similar to systemd's [`RestrictSUIDSGID=yes`](https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RestrictSUIDSGID=). > > In single-user computers, your scenario doesn't make sense. The 'user' in the scenario could be also an attacker, who temporarily gains limited access using for example browser vulnerabilities or indirectly via an organization's shared network file system. We don't know well in advance what makes sense for all future attack scenarios and every little bit of extra security can help weaken the attacker's capabilities. There's no global switch 'security=on' which could block all possible attacks. Instead there are yet unknown weaknesses of various sizes which may lead to vulnerabilities and exploits, and attempts to make attackers' lives more difficult to counter the possibility of weaknesses.

gitea-mirror commented

2026-05-05 09:23:04 -06:00

Author

Owner

@crocket commented on GitHub (Oct 15, 2021):

For nogroups auto to eliminate all supplementary groups on logind systems and keep relevant groups on other systems makes sense because it improves convenience without reducing security.

Convenience matters because

If it's very difficult to use firejail, people won't use it. Not using firejail is a lot worse than keeping some supplementary groups. Most people don't have enough patience or enough attention span to make firejail work on systems without logind.
It saves people's time. Time is a valuable resource. It's more valuable than money. We should consider time as one of many factors we optimize for. Security and privacy are important, too.

@crocket commented on GitHub (Oct 15, 2021): For `nogroups auto` to eliminate all supplementary groups on logind systems and keep relevant groups on other systems makes sense because it improves convenience without reducing security. Convenience matters because * If it's very difficult to use firejail, people won't use it. Not using firejail is a lot worse than keeping some supplementary groups. Most people don't have enough patience or enough attention span to make firejail work on systems without logind. * It saves people's time. Time is a valuable resource. It's more valuable than money. We should consider time as one of many factors we optimize for. Security and privacy are important, too.

gitea-mirror commented

2026-05-05 09:23:05 -06:00

Author

Owner

@kmk3 commented on GitHub (Oct 23, 2021):

@rusty-snake commented on Oct 15:

If we keep adding stuff without eliminating lines, we may end up with
something like ignore ignore ignore nogroups

ignore nogroups is enough.

What about nogroups <all|auto|none>?
nogroups all (and alias nogroups for backward compatibility) will drop
all supplementary groups. (and noroot will not change groups noroot
removes all user groups, nogroups redundant
#3303)

nogroups none will keep all groups (maybe we don't need this as it is the
same as not using nogroups and just complicates things)
nogroups auto will autodetect which groups it should keep (whitelisting)
if !arg_nosound:
    drop_group("audio")
if !arg_novideo:
    drop_group("video")
if !arg_nodvd:
    drop_group("cdrom")
if !arg_noinput:
    drop_group("input")
if !arg_no3d: // /dev/dri/card0 has group video
    drop_group("render")
if !arg_noprinters:
    drop_group("lp")
in case other group names are used, we can provide mappings in
firejail.config

I really like the mapping of the "no" options to groups; it seems like an
obvious thing to do. Luckily, it looks like it wouldn't be hard to do
(refactoring to making it work without ACLs is another story though); see the
following related PR:

#4632

So, considering the following extra groups from @rusty-snake's code:

cdrom
input
render
lp

Thoughts on adding them to the hardcoded "allowed groups" lists and dropping
them based on the no options?

@topimiettinen commented on Oct 15:

if !arg_nosound:
    drop_group("audio")
if !arg_novideo:
    drop_group("video")
if !arg_nodvd:
    drop_group("cdrom")
if !arg_noinput:
    drop_group("input")
if !arg_no3d: // /dev/dri/card0 has group video
    drop_group("render")
if !arg_noprinters:
    drop_group("lp")
This could work well if also coupled with the logind check, so users on
distros with logind would not get extra permissions but others would get at
least some groups automatically when needed.

After looking at the code, I think that combining the above ideas would be
a straightforward way to do it:

Dropping groups based on nosound, novideo, etc
Checking whether (e)logind is running before handling nogroups

And it wouldn't really require any new command or option.

So how about we do the following:

If nosound, always drop audio group and block sound devices in /dev
If novideo, always drop video group and block video devices in /dev

("always" above means "regardless of noroot and nogroups/(e)logind")

If nogroups and (e)logind is running, drop all non-hardcoded groups
If nogroups and (e)logind is not running, keep the audio and video groups
(if not already dropped) and the hardcoded groups and drop all other groups

Currently, the audio/video groups are only dropped if noroot is used
(AFAICT).

@crocket Can you think of any other group that could be needed? Maybe the lp
group when using the new noprinters command?

#4607

Note: From what I've seen, using a variable like e.g.: have_seat_acls where
required might not be something trivial to do, since nogroups is used in
multiple places and since in some of them it currently means just "drop all
groups" in some places. But I haven't looked too much into it.

Maybe there could be a drop_groups(const char* groupnames[]) function (to
only drop certain groups and keep the rest) besides the
clean_supplementary_groups one (which drops all but certain hardcoded
groups)?

Misc: I had written some more comments, but since I wrote some code related to
the above (on #4632 and on a WIP branch), I'd like to get it out of the way
first.

@kmk3 commented on GitHub (Oct 23, 2021): @rusty-snake commented [on Oct 15](https://github.com/netblue30/firejail/issues/4603#issuecomment-944046299): > > If we keep adding stuff without eliminating lines, we may end up with > > something like `ignore ignore ignore nogroups` > > `ignore nogroups` is enough. > > What about `nogroups <all|auto|none>`? > > * `nogroups all` (and alias `nogroups` for backward compatibility) will drop > all supplementary groups. (and `noroot` will not change groups [noroot > removes all user groups, nogroups redundant > #3303](https://github.com/netblue30/firejail/issues/3303)) > > * `nogroups none` will keep all groups (maybe we don't need this as it is the > same as not using `nogroups` and just complicates things) > > * `nogroups auto` will autodetect which groups it should keep (whitelisting) > > ```js > if !arg_nosound: > drop_group("audio") > if !arg_novideo: > drop_group("video") > if !arg_nodvd: > drop_group("cdrom") > if !arg_noinput: > drop_group("input") > if !arg_no3d: // /dev/dri/card0 has group video > drop_group("render") > if !arg_noprinters: > drop_group("lp") > ``` > > in case other group names are used, we can provide mappings in > firejail.config I really like the mapping of the "no" options to groups; it seems like an obvious thing to do. Luckily, it looks like it wouldn't be hard to do (refactoring to making it work without ACLs is another story though); see the following related PR: * #4632 So, considering the following extra groups from @rusty-snake's code: * cdrom * input * render * lp Thoughts on adding them to the hardcoded "allowed groups" lists and dropping them based on the `no` options? @topimiettinen commented [on Oct 15](https://github.com/netblue30/firejail/issues/4603#issuecomment-944161473): > > ```js > > if !arg_nosound: > > drop_group("audio") > > if !arg_novideo: > > drop_group("video") > > if !arg_nodvd: > > drop_group("cdrom") > > if !arg_noinput: > > drop_group("input") > > if !arg_no3d: // /dev/dri/card0 has group video > > drop_group("render") > > if !arg_noprinters: > > drop_group("lp") > > ``` > > This could work well if also coupled with the logind check, so users on > distros with logind would not get extra permissions but others would get at > least some groups automatically when needed. After looking at the code, I think that combining the above ideas would be a straightforward way to do it: * Dropping groups based on `nosound`, `novideo`, etc * Checking whether (e)logind is running before handling `nogroups` And it wouldn't really require any new command or option. So how about we do the following: * If `nosound`, always drop audio group and block sound devices in /dev * If `novideo`, always drop video group and block video devices in /dev ("always" above means "regardless of `noroot` and `nogroups`/(e)logind") * If `nogroups` and (e)logind is running, drop all non-hardcoded groups * If `nogroups` and (e)logind is not running, keep the audio and video groups (if not already dropped) and the hardcoded groups and drop all other groups Currently, the audio/video groups are only dropped if `noroot` is used (AFAICT). @crocket Can you think of any other group that could be needed? Maybe the lp group when using the new `noprinters` command? * #4607 Note: From what I've seen, using a variable like e.g.: `have_seat_acls` where required might not be something trivial to do, since `nogroups` is used in multiple places and since in some of them it currently means just "drop all groups" in some places. But I haven't looked too much into it. Maybe there could be a `drop_groups(const char* groupnames[])` function (to only drop certain groups and keep the rest) besides the `clean_supplementary_groups` one (which drops all but certain hardcoded groups)? --- Misc: I had written some more comments, but since I wrote some code related to the above (on #4632 and on a WIP branch), I'd like to get it out of the way first.

gitea-mirror commented

2026-05-05 09:23:05 -06:00

Author

Owner

@crocket commented on GitHub (Oct 24, 2021):

New options to consider with regard to nogroups:

noprinters

Existing options to consider with regard to nogroups:

--no3d
--nodvd
--noinput
--nosound
--notv
--nou2f
--novideo

Other considerations:

noroot should not drop groups?

@crocket commented on GitHub (Oct 24, 2021): New options to consider with regard to `nogroups`: * `noprinters` Existing options to consider with regard to `nogroups`: * `--no3d` * `--nodvd` * `--noinput` * `--nosound` * `--notv` * `--nou2f` * `--novideo` Other considerations: * `noroot` should not drop groups?

gitea-mirror commented

2026-05-05 09:23:07 -06:00

Author

Owner

@kmk3 commented on GitHub (Oct 26, 2021):

@crocket commented on Oct 24:

New options to consider with regard to nogroups:

noprinters

Existing options to consider with regard to nogroups:

--no3d

--nodvd

--noinput

--nosound

--notv

--nou2f

--novideo

Which groups would notv and nou2f map to?

Other considerations:

noroot should not drop groups?

I think it's intended to drop only the groups that are related to non-system
users. That is, all groups with a gid between GID_MIN and GID_MAX, as
defined on login.defs(5).

From my testing, the option appears to be working correctly (at least by
itself):

$ firejail --quiet --noprofile --noroot \
  getent group | cut -f 3 -d : | tr '\n' '\000' | xargs -0 -I '{}' sh -c \
  "test '{}' -ge 1000 && printf '%s\n' '{}'"
65534
1000

The following commands output the same amount of groups inside and outside of
firejail (so no system group appears to be dropped):

getent group | cut -f 3 -d : | tr '\n' '\000' | xargs -0 -I '{}' sh -c \
  "test '{}' -lt 1000 && printf '%s\n' '{}'" | wc -l

@kmk3 commented on GitHub (Oct 26, 2021): @crocket commented [on Oct 24](https://github.com/netblue30/firejail/issues/4603#issuecomment-950298918): > New options to consider with regard to `nogroups`: > > * `noprinters` > > Existing options to consider with regard to `nogroups`: > > * `--no3d` > * `--nodvd` > * `--noinput` > * `--nosound` > * `--notv` > * `--nou2f` > * `--novideo` Which groups would `notv` and `nou2f` map to? > Other considerations: > > * `noroot` should not drop groups? I think it's intended to drop only the groups that are related to non-system users. That is, all groups with a gid between `GID_MIN` and `GID_MAX`, as defined on login.defs(5). From my testing, the option appears to be working correctly (at least by itself): ```console $ firejail --quiet --noprofile --noroot \ getent group | cut -f 3 -d : | tr '\n' '\000' | xargs -0 -I '{}' sh -c \ "test '{}' -ge 1000 && printf '%s\n' '{}'" 65534 1000 ``` The following commands output the same amount of groups inside and outside of firejail (so no system group appears to be dropped): ```sh getent group | cut -f 3 -d : | tr '\n' '\000' | xargs -0 -I '{}' sh -c \ "test '{}' -lt 1000 && printf '%s\n' '{}'" | wc -l ```

gitea-mirror commented

2026-05-05 09:23:07 -06:00

Author

Owner

@crocket commented on GitHub (Oct 26, 2021):

Which groups would notv and nou2f map to?

nou2f blocks /dev/hidraw0 which belongs to root group.
notv blocks /dev/dvb which doesn't exist on my system. So, I don't know which group it belongs to.

I think it's intended to drop only the groups that are related to non-system users.

Man page doesn't say anything about that.

@crocket commented on GitHub (Oct 26, 2021): > Which groups would notv and nou2f map to? `nou2f` blocks `/dev/hidraw0` which belongs to `root` group. `notv` blocks `/dev/dvb` which doesn't exist on my system. So, I don't know which group it belongs to. > I think it's intended to drop only the groups that are related to non-system users. Man page doesn't say anything about that.

gitea-mirror commented

2026-05-05 09:23:07 -06:00

Author

Owner

@rusty-snake commented on GitHub (Oct 26, 2021):

nou2f blocks /dev/hidraw0

FTR: It blocks /dev/hidraw[0-9] and /dev/usb

efbf74e124/src/firejail/fs_dev.c (L81-L91)

@rusty-snake commented on GitHub (Oct 26, 2021): > `nou2f` blocks `/dev/hidraw0` FTR: It blocks `/dev/hidraw[0-9]` and `/dev/usb` https://github.com/netblue30/firejail/blob/efbf74e12421c97d8a1756649422f83f4a0b7e50/src/firejail/fs_dev.c#L81-L91

gitea-mirror commented

2026-05-05 09:23:07 -06:00

Author

Owner

@crocket commented on GitHub (Jan 2, 2022):

Can this be considered fixed now?

@crocket commented on GitHub (Jan 2, 2022): Can this be considered fixed now?

gitea-mirror commented

2026-05-05 09:23:08 -06:00

Author

Owner

@kmk3 commented on GitHub (Jan 3, 2022):

@crocket commented on Jan 2:

Can this be considered fixed now?

Yes; thanks for the reminder.

@kmk3 commented on GitHub (Jan 3, 2022): @crocket commented [on Jan 2](https://github.com/netblue30/firejail/issues/4603#issuecomment-1003698727): > Can this be considered fixed now? Yes; thanks for the reminder.

Rows
Columns

[GH-ISSUE #4603] Feature Request: Logind conditional #2718

Is your feature request related to a problem? Please describe.

Describe the solution you'd like