nogroups still drops audio group and all other supplementary groups. #4951

crocket · 2022-02-16T09:56:33Z

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

The text was updated successfully, but these errors were encountered:

reinerh · 2022-02-16T20:16:25Z

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".

rusty-snake · 2022-02-16T20:21:05Z

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

#4725, #4732, #4603

firejail/RELNOTES

Lines 32 to 35 in 271edbb

 * modifs: nogroups now stopped causing certain system groups to be dropped, 

 which are now controlled by the relevant "no" options instead (such as 

 nosound -> drop audio group), which fixes device access issues on systems 

 not using (e)logind (such as with seatd) (#4632 #4725 #4732 #4851)

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

👍
:+2:
#4725 (comment)

reinerh · 2022-02-16T20:27:45Z

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

kmk3 · 2022-02-17T01:13:12Z

@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

firejail/RELNOTES

Lines 32 to 35 in 271edbb

* modifs: nogroups now stopped causing certain system groups to be dropped,

which are now controlled by the relevant "no" options instead (such as

nosound -> drop audio group), which fixes device access issues on systems

not using (e)logind (such as with seatd) (#4632 #4725 #4732 #4851)

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.

crocket · 2022-02-17T04:00:07Z

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 · 2022-02-17T08:01:26Z

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.

rusty-snake · 2022-02-17T08:02:39Z

#4930 and #4933

crocket · 2022-03-10T11:57:08Z

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

amano-kenji · 2023-03-29T04:30:52Z

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 · 2023-03-29T11:50:02Z

I think

firejail/src/firejail/util.c

Lines 107 to 127 in f95bbb6

 int check_can_drop_all_groups() { 

 static int can_drop_all_groups = -1; 

 // Avoid needlessly checking (and printing) things twice 

 if (can_drop_all_groups != -1) 

 goto out; 

 // nvidia cards require video group; ignore nogroups 

 if (access("/dev/nvidiactl", R_OK) == 0 && arg_no3d == 0) { 

 fwarning("NVIDIA card detected, nogroups command ignored\n"); 

 can_drop_all_groups = 0; 

 goto out; 

 } 

 /* When we are not sure that the system has working seat-based ACLs 

  * (e.g.: probably yes on (e)udev + (e)logind, probably not on eudev + 

  * seatd), supplementary groups (e.g.: audio and input) might be needed 

  * to avoid breakage (e.g.: audio or gamepads not working). See #4600 

  * and #4603. 

  */ 

 if (access("/run/systemd/seats/", F_OK) != 0) {

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 · 2023-03-29T12:11:13Z

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

amano-kenji · 2023-03-29T13:15:36Z

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 · 2023-03-29T13:23:06Z

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 · 2023-03-29T13:28:19Z

What should we do about this?

kmk3 · 2023-03-29T14:24:54Z

@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).

Document the uaccess mechanism / dynamic device permissions systemd/systemd#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.

amano-kenji · 2023-03-30T03:17:57Z

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 · 2023-03-30T03:31:05Z

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?

crocket changed the title ~~nogroups still drops audio group and all other groups.~~ nogroups still drops audio group and all other supplementary groups. Feb 16, 2022

amano-kenji mentioned this issue Mar 30, 2023

firejail --appimage doesn't have supplementary groups required for device access #5748

Closed

7 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

nogroups still drops audio group and all other supplementary groups. #4951

nogroups still drops audio group and all other supplementary groups. #4951

crocket commented Feb 16, 2022

reinerh commented Feb 16, 2022 •

edited

Loading

rusty-snake commented Feb 16, 2022 •

edited

Loading

reinerh commented Feb 16, 2022

kmk3 commented Feb 17, 2022

crocket commented Feb 17, 2022 •

edited

Loading

crocket commented Feb 17, 2022 •

edited

Loading

rusty-snake commented Feb 17, 2022

crocket commented Mar 10, 2022 •

edited

Loading

amano-kenji commented Mar 29, 2023 •

edited

Loading

amano-kenji commented Mar 29, 2023 •

edited

Loading

amano-kenji commented Mar 29, 2023

amano-kenji commented Mar 29, 2023 •

edited

Loading

amano-kenji commented Mar 29, 2023 •

edited

Loading

amano-kenji commented Mar 29, 2023

kmk3 commented Mar 29, 2023

amano-kenji commented Mar 30, 2023 •

edited

Loading

amano-kenji commented Mar 30, 2023 •

edited

Loading

nogroups still drops audio group and all other supplementary groups. #4951

nogroups still drops audio group and all other supplementary groups. #4951

Comments

crocket commented Feb 16, 2022

Description

Steps to Reproduce

Expected behavior

Actual behavior

Behavior without a profile

Environment

reinerh commented Feb 16, 2022 • edited Loading

rusty-snake commented Feb 16, 2022 • edited Loading

reinerh commented Feb 16, 2022

kmk3 commented Feb 17, 2022

crocket commented Feb 17, 2022 • edited Loading

crocket commented Feb 17, 2022 • edited Loading

rusty-snake commented Feb 17, 2022

crocket commented Mar 10, 2022 • edited Loading

amano-kenji commented Mar 29, 2023 • edited Loading

amano-kenji commented Mar 29, 2023 • edited Loading

amano-kenji commented Mar 29, 2023

amano-kenji commented Mar 29, 2023 • edited Loading

amano-kenji commented Mar 29, 2023 • edited Loading

amano-kenji commented Mar 29, 2023

kmk3 commented Mar 29, 2023

amano-kenji commented Mar 30, 2023 • edited Loading

amano-kenji commented Mar 30, 2023 • edited Loading

reinerh commented Feb 16, 2022 •

edited

Loading

rusty-snake commented Feb 16, 2022 •

edited

Loading

crocket commented Feb 17, 2022 •

edited

Loading

crocket commented Feb 17, 2022 •

edited

Loading

crocket commented Mar 10, 2022 •

edited

Loading

amano-kenji commented Mar 29, 2023 •

edited

Loading

amano-kenji commented Mar 29, 2023 •

edited

Loading

amano-kenji commented Mar 29, 2023 •

edited

Loading

amano-kenji commented Mar 29, 2023 •

edited

Loading

amano-kenji commented Mar 30, 2023 •

edited

Loading

amano-kenji commented Mar 30, 2023 •

edited

Loading