[GH-ISSUE #4951] nogroups still drops audio group and all other supplementary groups.

gitea-mirror commented

2026-05-05 09:29:09 -06:00

Owner

Originally created by @crocket on GitHub (Feb 16, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4951

Description

I thought nogroups wasn't going to drop audio group on firejail 0.9.68.
But, I was wrong.

Steps to Reproduce

$ firejail --noprofile --nogroups bash
$ groups
Only primary-group for the user, and no supplementary group.

Expected behavior

Relevant supplementary groups should be preserved.

Actual behavior

Only user's primary group is preserved.

Behavior without a profile

The same

Environment

Linux distribution and version: Gentoo Linux
Firejail version: 0.9.68

Originally created by @crocket on GitHub (Feb 16, 2022). Original GitHub issue: https://github.com/netblue30/firejail/issues/4951 ### Description I thought nogroups wasn't going to drop audio group on firejail 0.9.68. But, I was wrong. ### Steps to Reproduce ``` $ firejail --noprofile --nogroups bash $ groups Only primary-group for the user, and no supplementary group. ``` ### Expected behavior Relevant supplementary groups should be preserved. ### Actual behavior Only user's primary group is preserved. ### Behavior without a profile The same ### Environment - Linux distribution and version: Gentoo Linux - Firejail version: 0.9.68

gitea-mirror commented

2026-05-05 09:29:11 -06:00

Author

Owner

@reinerh commented on GitHub (Feb 16, 2022):

Expected behavior

Relevant supplementary groups should be preserved.

I don't know why you expect that. That's not what I would expect, and it's also documented differently:

       --nogroups
              Disable supplementary groups. Without this option, supplementary groups are enabled for the user starting the sandbox. For root user supplementary groups are always disabled.

              Note: By default all regular user groups are removed with the exception of the current user. This can be changed using --allusers command option.

I don't think --nogroups should be changed to mean "no groups except of some groups that some users might want to keep".

@reinerh commented on GitHub (Feb 16, 2022): > Expected behavior > > Relevant supplementary groups should be preserved. I don't know why you expect that. That's not what I would expect, and it's also documented differently: ``` --nogroups Disable supplementary groups. Without this option, supplementary groups are enabled for the user starting the sandbox. For root user supplementary groups are always disabled. Note: By default all regular user groups are removed with the exception of the current user. This can be changed using --allusers command option. ``` I don't think `--nogroups` should be changed to mean "no groups except of some groups that some users might want to keep".

gitea-mirror commented

2026-05-05 09:29:12 -06:00

Author

Owner

@rusty-snake commented on GitHub (Feb 16, 2022):

I don't know why you expect that. That's not what I would expect, and it's also documented differently:

#4725, #4732, #4603

271edbbcf5/RELNOTES (L32-L35)

I don't think --nogroups should be changed to mean "no groups except of some groups that some users might want to keep".

👍
:+2:
https://github.com/netblue30/firejail/pull/4725#issuecomment-982898312

@rusty-snake commented on GitHub (Feb 16, 2022): > I don't know why you expect that. That's not what I would expect, and it's also documented differently: #4725, #4732, #4603 https://github.com/netblue30/firejail/blob/271edbbcf560e652c415839547a46e94b5b16a7f/RELNOTES#L32-L35 > I don't think --nogroups should be changed to mean "no groups except of some groups that some users might want to keep". :+1: :+2: https://github.com/netblue30/firejail/pull/4725#issuecomment-982898312

gitea-mirror commented

2026-05-05 09:29:13 -06:00

Author

Owner

@reinerh commented on GitHub (Feb 16, 2022):

Thanks. Somehow I missed that change. We should at least fix the manpage to document this new behaviour then.

@reinerh commented on GitHub (Feb 16, 2022): Thanks. Somehow I missed that change. We should at least fix the manpage to document this new behaviour then.

gitea-mirror commented

2026-05-05 09:29:13 -06:00

Author

Owner

@kmk3 commented on GitHub (Feb 17, 2022):

@rusty-snake commented on Feb 16:

I don't know why you expect that. That's not what I would expect, and it's
also documented differently:

#4725, #4732, #4603

271edbbcf5/RELNOTES (L32-L35)

I should have made it clearer in there that this only applies to systems not
running (e)logind.

I don't think --nogroups should be changed to mean "no groups except of
some groups that some users might want to keep".

+1 :+2:

Again, on a system where (e)logind is running, there should be no extra group
keeping at all with nogroups compared to 0.9.66. In fact, there should be
less group keeping on such systems, as now the audio/video groups are not
always kept anymore when there is noroot + no nogroups; they are dropped
when noaudio/novideo are used in such case (see #4632).

When nogroups is enabled, the changes in 0.9.68 should only affect systems
not running (e)logind.

To reiterate, udev only applies seat-based ACLs if it detects that (e)logind is
running (and thus having supplementary groups is not necessary). If it does
not set up the ACLs, then keeping the supplementary groups is required for
basic group-related functionality (such as audio). Just like on systems with
nvidia, where disabling nogroups is required in order to have hardware
acceleration (this workaround was already being done in the code on 0.9.66).

Before 0.9.68, every user of e.g.: seatd would have to put ignore nogroups
(and maybe ignore noroot) on e.g.: globals.local in order to have functioning
audio in the sandbox. With 0.9.68, it should work seamlessly. If that's not
the case, then it's a bug.

I think it would be easier to explain if everyone just read the code. The
relevant changes are minimal. Here they are, using the audio group as the
example:

Handling noroot / nogroups on main.c (note that both code blocks are inside
if (arg_noroot)):

https://github.com/netblue30/firejail/blob/0.9.66/src/firejail/main.c#L3091-L3111
https://github.com/netblue30/firejail/blob/0.9.68/src/firejail/main.c#L3165-L3173

Dropping supplementary groups:

https://github.com/netblue30/firejail/blob/0.9.66/src/firejail/util.c#L119-L146
https://github.com/netblue30/firejail/blob/0.9.68/src/firejail/util.c#L182-L202

This is what disables nogroups on 0.9.66 (nvidia + no no3d):

https://github.com/netblue30/firejail/blob/0.9.66/src/firejail/profile.c#L413-L422

This is what disables nogroups on 0.9.68 ((nvidia + no no3d) or no (e)logind):

https://github.com/netblue30/firejail/blob/0.9.68/src/firejail/util.c#L106-L139

#4725 (comment)

What do you want to do then? Drop both workarounds, including the nvidia one?

That might make the code and the documentation simpler, but personally I don't
think that such changes would be that significant to warrant having audio
and/or hardware acceleration broken by default on every program on a
non-trivial amount of systems.

@kmk3 commented on GitHub (Feb 17, 2022): @rusty-snake commented [on Feb 16](https://github.com/netblue30/firejail/issues/4951#issuecomment-1042173421): > > I don't know why you expect that. That's not what I would expect, and it's > > also documented differently: > > #4725, #4732, #4603 > > https://github.com/netblue30/firejail/blob/271edbbcf560e652c415839547a46e94b5b16a7f/RELNOTES#L32-L35 I should have made it clearer in there that this only applies to systems not running (e)logind. > > I don't think --nogroups should be changed to mean "no groups except of > > some groups that some users might want to keep". > > +1 :+2: Again, on a system where (e)logind is running, there should be no extra group keeping at all with `nogroups` compared to 0.9.66. In fact, there should be less group keeping on such systems, as now the audio/video groups are not always kept anymore when there is `noroot` + no `nogroups`; they are dropped when `noaudio`/`novideo` are used in such case (see #4632). When `nogroups` is enabled, the changes in 0.9.68 should only affect systems not running (e)logind. To reiterate, udev only applies seat-based ACLs if it detects that (e)logind is running (and thus having supplementary groups is not necessary). If it does not set up the ACLs, then keeping the supplementary groups is required for basic group-related functionality (such as audio). Just like on systems with nvidia, where disabling `nogroups` is required in order to have hardware acceleration (this workaround was already being done in the code on 0.9.66). Before 0.9.68, every user of e.g.: seatd would have to put `ignore nogroups` (and maybe `ignore noroot`) on e.g.: globals.local in order to have functioning audio in the sandbox. With 0.9.68, it should work seamlessly. If that's not the case, then it's a bug. I think it would be easier to explain if everyone just read the code. The relevant changes are minimal. Here they are, using the audio group as the example: Handling `noroot` / `nogroups` on main.c (note that both code blocks are inside `if (arg_noroot)`): https://github.com/netblue30/firejail/blob/0.9.66/src/firejail/main.c#L3091-L3111 https://github.com/netblue30/firejail/blob/0.9.68/src/firejail/main.c#L3165-L3173 Dropping supplementary groups: https://github.com/netblue30/firejail/blob/0.9.66/src/firejail/util.c#L119-L146 https://github.com/netblue30/firejail/blob/0.9.68/src/firejail/util.c#L182-L202 This is what disables `nogroups` on 0.9.66 (nvidia + no `no3d`): https://github.com/netblue30/firejail/blob/0.9.66/src/firejail/profile.c#L413-L422 This is what disables `nogroups` on 0.9.68 ((nvidia + no `no3d`) or no (e)logind): https://github.com/netblue30/firejail/blob/0.9.68/src/firejail/util.c#L106-L139 > [#4725 (comment)](https://github.com/netblue30/firejail/pull/4725#issuecomment-982898312) What do you want to do then? Drop both workarounds, including the nvidia one? That might make the code and the documentation simpler, but personally I don't think that such changes would be _that_ significant to warrant having audio and/or hardware acceleration broken by default on every program on a non-trivial amount of systems.

gitea-mirror commented

2026-05-05 09:29:14 -06:00

Author

Owner

@crocket commented on GitHub (Feb 17, 2022):

Suddenly, nogroups doesn't drop audio and video groups without profile.

$ firejail --noprofile --nogroups bash
$ groups
primary-group supplementary-groups...

This issue occurs with librewolf.profile.

$ librewolf
Warning: logind not detected, nogroups command ignored
Warning: logind not detected, nogroups command ignored
Warning: logind not detected, nogroups command ignored
Warning: logind not detected, nogroups command ignored
Warning: logind not detected, nogroups command ignored
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,
Warning: logind not detected, nogroups command ignored
Warning: logind not detected, nogroups command ignored
Child process initialized in 145.39 ms
$ firejail --join=pid-of-librewolf-sandbox
$ groups
primary-group

@crocket commented on GitHub (Feb 17, 2022): Suddenly, `nogroups` doesn't drop audio and video groups without profile. ``` $ firejail --noprofile --nogroups bash $ groups primary-group supplementary-groups... ``` This issue occurs with librewolf.profile. ``` $ librewolf Warning: logind not detected, nogroups command ignored Warning: logind not detected, nogroups command ignored Warning: logind not detected, nogroups command ignored Warning: logind not detected, nogroups command ignored Warning: logind not detected, nogroups command ignored Seccomp list in: !chroot, check list: @default-keep, prelist: unknown, Warning: logind not detected, nogroups command ignored Warning: logind not detected, nogroups command ignored Child process initialized in 145.39 ms $ firejail --join=pid-of-librewolf-sandbox $ groups primary-group ```

gitea-mirror commented

2026-05-05 09:29:15 -06:00

Author

Owner

@crocket commented on GitHub (Feb 17, 2022):

Suddenly, librewolf stopped requiring ignore nogroups for audio group.
When I execute anki, I see this.

Warning: skipping alternatives for private /etc
Warning: skipping hostname for private /etc
Warning: skipping pki for private /etc
Warning: skipping Trolltech.conf for private /etc
Private /etc installed in 25.81 ms
Private /usr/etc installed in 0.00 ms
Warning: logind not detected, nogroups command ignored
Warning: cleaning all supplementary groups
Warning: logind not detected, nogroups command ignored
Warning: cleaning all supplementary groups
Warning: logind not detected, nogroups command ignored
Warning: cleaning all supplementary groups
Warning: logind not detected, nogroups command ignored
Warning: cleaning all supplementary groups
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,
Warning: logind not detected, nogroups command ignored
Warning: logind not detected, nogroups command ignored
Warning: cleaning all supplementary groups
Warning: Cannot confine the application using AppArmor.

@crocket commented on GitHub (Feb 17, 2022): Suddenly, librewolf stopped requiring `ignore nogroups` for audio group. When I execute anki, I see this. ``` Warning: skipping alternatives for private /etc Warning: skipping hostname for private /etc Warning: skipping pki for private /etc Warning: skipping Trolltech.conf for private /etc Private /etc installed in 25.81 ms Private /usr/etc installed in 0.00 ms Warning: logind not detected, nogroups command ignored Warning: cleaning all supplementary groups Warning: logind not detected, nogroups command ignored Warning: cleaning all supplementary groups Warning: logind not detected, nogroups command ignored Warning: cleaning all supplementary groups Warning: logind not detected, nogroups command ignored Warning: cleaning all supplementary groups Seccomp list in: !chroot, check list: @default-keep, prelist: unknown, Warning: logind not detected, nogroups command ignored Warning: logind not detected, nogroups command ignored Warning: cleaning all supplementary groups Warning: Cannot confine the application using AppArmor. ```

gitea-mirror commented

2026-05-05 09:29:16 -06:00

Author

Owner

@rusty-snake commented on GitHub (Feb 17, 2022):

#4930 and #4933

@rusty-snake commented on GitHub (Feb 17, 2022): #4930 and #4933

gitea-mirror commented

2026-05-05 09:29:16 -06:00

Author

Owner

@crocket commented on GitHub (Mar 10, 2022):

https://git.sr.ht/~kennylevinsen/pam_uaccess replaces logind's uaccess functionality.

@crocket commented on GitHub (Mar 10, 2022): https://git.sr.ht/~kennylevinsen/pam_uaccess replaces logind's uaccess functionality.

gitea-mirror commented

2026-05-05 09:29:17 -06:00

Author

Owner

@amano-kenji commented on GitHub (Mar 29, 2023):

This is still a problem. I use seatd and have to have ignore nogroups and ignore noroot in globals.local.

It seems to me that nogroups is still broken with regard to supplementary groups. Appimage also drops supplementary groups.

@amano-kenji commented on GitHub (Mar 29, 2023): This is still a problem. I use seatd and have to have `ignore nogroups` and `ignore noroot` in `globals.local`. It seems to me that `nogroups` is still broken with regard to supplementary groups. Appimage also drops supplementary groups.

gitea-mirror commented

2026-05-05 09:29:18 -06:00

Author

Owner

@amano-kenji commented on GitHub (Mar 29, 2023):

I think
f95bbb6f6e/src/firejail/util.c (L107-L127)
is the problem.

Despite my efforts to disable elogind on my system, it is still installed and running alongside seatd.

However, seat-based ACL doesn't seem to be working because sway is using seatd on gentoo linux for seat management.

@amano-kenji commented on GitHub (Mar 29, 2023): I think https://github.com/netblue30/firejail/blob/f95bbb6f6e517f43fd0f3d7129f238fe817beca4/src/firejail/util.c#L107-L127 is the problem. Despite my efforts to disable elogind on my system, it is still installed and running alongside seatd. However, seat-based ACL doesn't seem to be working because sway is using seatd on gentoo linux for seat management.

gitea-mirror commented

2026-05-05 09:29:19 -06:00

Author

Owner

@amano-kenji commented on GitHub (Mar 29, 2023):

elogind is not launched automatically during boot and sway login. But, it was launched at some point by some program?

@amano-kenji commented on GitHub (Mar 29, 2023): elogind is not launched automatically during boot and sway login. But, it was launched at some point by some program?

gitea-mirror commented

2026-05-05 09:29:19 -06:00

Author

Owner

@amano-kenji commented on GitHub (Mar 29, 2023):

I finally figured out what launched elogind.

dino.profile has the following lines that cause system d-bus to launch elogind.

# Integration with systemd-logind or elogind
dbus-system.talk org.freedesktop.login1

After elogind appears, appimage loses access to ALSA devices and input devices with or without

ignore noroot
ignore nogroups

in globals.local. However, after elogind appears, ignore noroot and ignore nogroups are required in globals.local for various ALSA clients to access audio.

After killing elogind and deleting /run/systemd, appimage has access to devices again, and ignore noroot and ignore nogroups are not required in globals.local.

@amano-kenji commented on GitHub (Mar 29, 2023): I finally figured out what launched elogind. dino.profile has the following lines that cause system d-bus to launch elogind. ``` # Integration with systemd-logind or elogind dbus-system.talk org.freedesktop.login1 ``` After elogind appears, appimage loses access to ALSA devices and input devices with or without ``` ignore noroot ignore nogroups ``` in `globals.local`. However, after elogind appears, `ignore noroot` and `ignore nogroups` are required in `globals.local` for various ALSA clients to access audio. After killing elogind and deleting `/run/systemd`, appimage has access to devices again, and `ignore noroot` and `ignore nogroups` are not required in `globals.local`.

gitea-mirror commented

2026-05-05 09:29:20 -06:00

Author

Owner

@amano-kenji commented on GitHub (Mar 29, 2023):

Adding

ignore dbus-system.talk org.freedesktop.login1

to globals.local prevents elogind from being launched unwittingly. Having to figure out this little detail accidentally is infuriating. I'm furious.

@amano-kenji commented on GitHub (Mar 29, 2023): Adding ``` ignore dbus-system.talk org.freedesktop.login1 ``` to `globals.local` prevents elogind from being launched unwittingly. Having to figure out this little detail accidentally is infuriating. I'm furious.

gitea-mirror commented

2026-05-05 09:29:21 -06:00

Author

Owner

@amano-kenji commented on GitHub (Mar 29, 2023):

What should we do about this?

@amano-kenji commented on GitHub (Mar 29, 2023): What should we do about this?

gitea-mirror commented

2026-05-05 09:29:21 -06:00

Author

Owner

@kmk3 commented on GitHub (Mar 29, 2023):

@amano-kenji on Mar 29:

Adding
ignore dbus-system.talk org.freedesktop.login1
to globals.local prevents elogind from being launched unwittingly. Having
to figure out this little detail accidentally is infuriating. I'm furious.

Glad that at least a workaround was found.

@amano-kenji on Mar 29:

What should we do about this?

Checking for a path related to (e)logind is kind of a hack; it considers only
the most trivial case (whether elogind is/was running or not).

The more fool-proof way to do it would be to detect whether dynamic user ACLs /
uaccess is in effect.

Though no idea what would be the proper way to check for it.

The following excerpts explain how the permissions are supposed to work with
udev/logind:

From https://wiki.archlinux.org/title/udev#Allowing_regular_users_to_use_devices:

Allowing regular users to use devices

When a kernel driver initializes a device, the default state of the device
node is to be owned by root:root, with permissions 600. 1 This makes
devices inaccessible to regular users unless the driver changes the default,
or a udev rule in userspace changes the permissions.

The OWNER, GROUP, and MODE udev values can be used to provide access,
though one encounters the issue of how to make a device usable to all users
without an overly permissive mode. Ubuntu's approach is to create a
plugdev group that devices are added to, but this practice is not only
discouraged by the systemd developers, 2 but considered a bug when shipped
in udev rules on Arch (FS#35602). Another approach historically
employed, as described in Users and groups#Pre-systemd groups, is to
have different groups corresponding to categories of devices.

The modern recommended approach for systemd systems is to use a MODE of
660 to let the group use the device, and then attach a TAG named
uaccess 3. This special tag makes udev apply a dynamic user ACL to
the device node, which coordinates with systemd-logind(8) to make the
device usable to logged-in users.

From https://wiki.archlinux.org/title/Users_and_groups#Pre-systemd_groups:

Pre-systemd groups

Before arch migrated to systemd, users had to be manually added to
these groups in order to be able to access the corresponding devices. This
way has been deprecated in favour of udev marking the devices with a
uaccess tag and logind assigning the permissions to users
dynamically via ACLs according to which session is currently active.
Note that the session must not be broken for this to work (see General
troubleshooting#Session permissions to check it).

There are some notable exceptions which require adding a user to some of
these groups: for example if you want to allow users to access the device
even when they are not logged in. However, note that adding users to the
groups can even cause some functionality to break (for example, the audio
group will break fast user switching and allows applications to block
software mixing).

https://github.com/systemd/systemd/issues/4288
/usr/lib/udev/rules.d/50-udev-default.rules
/usr/lib/udev/rules.d/70-uaccess.rules

Also, keep in mind that this may be used instead:

@crocket on Mar 10, 2022:

https://git.sr.ht/~kennylevinsen/pam_uaccess replaces logind's uaccess
functionality.

@kmk3 commented on GitHub (Mar 29, 2023): @amano-kenji [on Mar 29](https://github.com/netblue30/firejail/issues/4951#issuecomment-1488605773): > Adding > > ``` > ignore dbus-system.talk org.freedesktop.login1 > ``` > > to `globals.local` prevents elogind from being launched unwittingly. Having > to figure out this little detail accidentally is infuriating. I'm furious. Glad that at least a workaround was found. @amano-kenji [on Mar 29](https://github.com/netblue30/firejail/issues/4951#issuecomment-1488614222): > What should we do about this? Checking for a path related to (e)logind is kind of a hack; it considers only the most trivial case (whether elogind is/was running or not). The more fool-proof way to do it would be to detect whether dynamic user ACLs / uaccess is in effect. Though no idea what would be the proper way to check for it. The following excerpts explain how the permissions are supposed to work with udev/logind: From <https://wiki.archlinux.org/title/udev#Allowing_regular_users_to_use_devices>: > Allowing regular users to use devices > > When a kernel driver initializes a device, the default state of the device > node is to be owned by `root:root`, with permissions `600`. [1] This makes > devices inaccessible to regular users unless the driver changes the default, > or a udev rule in userspace changes the permissions. > > The `OWNER`, `GROUP`, and `MODE` udev values can be used to provide access, > though one encounters the issue of how to make a device usable to all users > without an overly permissive mode. Ubuntu's approach is to create a > `plugdev` group that devices are added to, but this practice is not only > discouraged by the systemd developers, [2] but considered a bug when shipped > in udev rules on Arch ([FS#35602][FS35602]). Another approach historically > employed, as described in [Users and groups#Pre-systemd groups][a1], is to > have different groups corresponding to categories of devices. > > The modern recommended approach for systemd systems is to use a `MODE` of > `660` to let the group use the device, and then attach a `TAG` named > `uaccess` [3]. This special tag makes udev apply a [dynamic user ACL][a2] to > the device node, which coordinates with [systemd-logind(8)][a3] to make the > device usable to logged-in users. [1]: https://github.com/torvalds/linux/blob/v5.19/drivers/base/devtmpfs.c#L11-L13 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=815093 [3]: https://github.com/systemd/systemd/blob/main/rules.d/70-uaccess.rules.in [FS35602]: https://bugs.archlinux.org/task/35602 [a1]: https://wiki.archlinux.org/title/Users_and_groups#Pre-systemd_groups [a2]: https://github.com/systemd/systemd/blob/main/src/udev/udev-builtin-uaccess.c [a3]: (https://man.archlinux.org/man/systemd-logind.8) From <https://wiki.archlinux.org/title/Users_and_groups#Pre-systemd_groups>: > Pre-systemd groups > > Before arch migrated to [systemd][b1], users had to be manually added to > these groups in order to be able to access the corresponding devices. This > way has been deprecated in favour of [udev][b2] marking the devices with a > `uaccess` [tag][b3] and _logind_ assigning the permissions to users > dynamically via [ACLs][b4] according to which session is currently active. > Note that the session must not be broken for this to work (see [General > troubleshooting#Session permissions to check it][b5]). > > There are some notable exceptions which require adding a user to some of > these groups: for example if you want to allow users to access the device > even when they are not logged in. However, note that adding users to the > groups can even cause some functionality to break (for example, the `audio` > group will break fast user switching and allows applications to block > software mixing). [b1]: https://wiki.archlinux.org/title/Systemd [b2]: https://wiki.archlinux.org/title/Udev [b3]: https://github.com/systemd/systemd/blob/main/rules.d/70-uaccess.rules.in [b4]: https://wiki.archlinux.org/title/ACL [b5]: https://wiki.archlinux.org/title/General_troubleshooting#Session_permissions Related: * <https://github.com/systemd/systemd/issues/4288> * /usr/lib/udev/rules.d/50-udev-default.rules * /usr/lib/udev/rules.d/70-uaccess.rules Also, keep in mind that this may be used instead: @crocket [on Mar 10, 2022](https://github.com/netblue30/firejail/issues/4951#issuecomment-1063977920): > https://git.sr.ht/~kennylevinsen/pam_uaccess replaces logind's uaccess > functionality.

gitea-mirror commented

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

Author

Owner

@amano-kenji commented on GitHub (Mar 30, 2023):

Today, I discovered that ignore noroot and ignore nogroups are still required for ALSA even though elogind is not running.

I saw

Warning: cleaning all supplementary groups
Warning: cleaning all supplementary groups
Warning: cleaning all supplementary groups
Warning: cleaning all supplementary groups

with qutebrowser.profile. mpv.profile doesn't require ignore noroot and ignore nogroups for ALSA.

@amano-kenji commented on GitHub (Mar 30, 2023): Today, I discovered that `ignore noroot` and `ignore nogroups` are still required for ALSA even though elogind is not running. I saw ``` Warning: cleaning all supplementary groups Warning: cleaning all supplementary groups Warning: cleaning all supplementary groups Warning: cleaning all supplementary groups ``` with qutebrowser.profile. mpv.profile doesn't require `ignore noroot` and `ignore nogroups` for ALSA.

gitea-mirror commented

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

Author

Owner

@amano-kenji commented on GitHub (Mar 30, 2023):

It turns out that qutebrowser.profile was dropping supplementary groups with noroot because it didn't have /etc/group in the sandbox.

Adding private-etc group to qutebrowser.local prevents qutebrowser.profile from dropping all supplementary groups.

Why are supplementary groups so fragile?

@amano-kenji commented on GitHub (Mar 30, 2023): It turns out that qutebrowser.profile was dropping supplementary groups with `noroot` because it didn't have /etc/group in the sandbox. Adding `private-etc group` to `qutebrowser.local` prevents qutebrowser.profile from dropping all supplementary groups. Why are supplementary groups so fragile?

Rows
Columns

[GH-ISSUE #4951] nogroups still drops audio group and all other supplementary groups. #2830

Description

Steps to Reproduce

Expected behavior

Actual behavior

Behavior without a profile

Environment