#821424 pulseaudio: Do not put normal users on group audio

Package:
user-setup
Source:
user-setup
Submitter:
Corcodel Marian
Date:
2025-04-14 10:30:03 UTC
Severity:
wishlist
Tags:
#821424#5
Date:
2016-04-18 16:06:00 UTC
From:
To:
Any way pulseaudio is default sound server on debian and suggest to do not put
users on audio group because cross interference with alsa programs, now alsa is
for power users and pulseaudio is on default.
#821424#10
Date:
2016-04-18 16:36:37 UTC
From:
To:
Control: reassign -1 debian-installer

Pulseaudio does not add the user to the audio group. I'm guessing the
installer does, so I reassign there.
#821424#19
Date:
2016-04-18 18:01:20 UTC
From:
To:
We most certainly should not do that.
#821424#24
Date:
2016-04-18 18:21:37 UTC
From:
To:
Not only on debian-installer  , on all applications which use separate
users like asterisk, lightdm and so.
#821424#29
Date:
2016-04-18 18:04:22 UTC
From:
To:
But on setup process pulseaudio add user pulse on audio group.
#821424#34
Date:
2016-04-18 17:59:56 UTC
From:
To:
Pulseaudio  does not add users but can do erase all users from audio group.
#821424#39
Date:
2016-04-19 04:07:04 UTC
From:
To:
Quoting Felipe Sateler (fsateler@debian.org):


Adding the *first created* user to so-called "useful" groups is done
by user-setup.

We'll need a detaailed explanantion abou twhy this shouldn't be done
anymore, including all possible use cases of the installer.
#821424#46
Date:
2016-04-19 08:24:40 UTC
From:
To:
Just simple scenario i add asterisk user on group audio and asu user on
group audio result is bad
  here is result of lsoff:
root@marian1000:/home/asu# lsof /dev/snd/*
COMMAND   PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pulseaudi 961 asterisk  mem    CHR  116,4          9689 /dev/snd/pcmC0D0c
pulseaudi 961 asterisk  mem    CHR  116,3          9688 /dev/snd/pcmC0D0p
pulseaudi 961 asterisk   15u   CHR  116,2      0t0 9684 /dev/snd/controlC0
pulseaudi 961 asterisk   20u   CHR  116,2      0t0 9684 /dev/snd/controlC0
pulseaudi 961 asterisk   21u   CHR  116,3      0t0 9688 /dev/snd/pcmC0D0p
pulseaudi 961 asterisk   22u   CHR  116,2      0t0 9684 /dev/snd/controlC0
pulseaudi 961 asterisk   27u   CHR  116,2      0t0 9684 /dev/snd/controlC0
pulseaudi 961 asterisk   32u   CHR  116,4      0t0 9689 /dev/snd/pcmC0D0c

On my user asu pulseaudio have acces only on Dummy card .
Second on my audio application audacious  set to use  output to alsa
(assumed that pulseaudio is down)
same issue audacious take control of audio device and is no room for
pulseaudio.
#821424#51
Date:
2016-04-19 16:48:28 UTC
From:
To:
Quoting asu (asu@marian1000.go.ro):

So, what I understand is that this "audacious" thing shoulnd't take
control of the audio device, which it does because your user is member
of the audio group.

But, then, why launching audocious, then? That may sound like a silly
question, but, to my understanding, this is where the problem lies, am
I wrong?
#821424#56
Date:
2016-04-19 17:35:57 UTC
From:
To:
No matter this is strange on default DEBIAN PERMIT all clients on sound
device withtout exception. I ask on udev maintainer why?
#821424#61
Date:
2016-04-19 20:52:26 UTC
From:
To:
I don't know where you get this 'all possible use cases of the
installer' from.  Adding the first user to device access groups only
ever made sense for single-user desktop/mobile systems.  The installer
doesn't make device access work automagically for other local users of
multi-user desktop/mobile systems, nor does it do the right thing for
servers - where the first user is likely to be a remote admin (and
often one of a team of admins who shuld have the same privileges).

systemd installs udev rules (/lib/udev/rules.d/70-uaccess.rules) that
add the 'uaccess' tag to many kinds of devices.  systemd-logind then
adds locally logged-in users to the ACLs for the corresponding device
nodes.  This makes all or most of the groups for local device access
redundant.

I've done a quick test of removing myself from the device access groups
on a current GNOME desktop, with these results:

- audio:      redundant, I'm on the ACL for /dev/snd/*
- cdrom:      redundant, I'm on the ACL for /dev/sr0
- floppy:     unknown, but expect this to work like cdrom
- video:      redundant, I'm on the ACL for /dev/video0
- plugdev:    redundant, I'm on the ACL for /dev/bus/usb/002/006
- netdev:     redundant, I'm on the ACL for /dev/rfkill
- scanner:    redundant, I'm on the ACL for /dev/sg2
- bluetooth:  unknown, seems broken whether or not I'm a member of the group

The other groups (dip, debian-tor, lpadmin, sudo) make more sense,
though CUPS should probably be changed to treat sudo like lpadmin.

Ben.
#821424#66
Date:
2016-04-19 21:03:10 UTC
From:
To:
I don't believe the audio group has anything to do with this.  As I
explained, users logging in locally get access to sound cards even if
they aren't in the audio group.

I think the problem you have is one of:

1. Your X session doesn't start PA automatically
2. ALSA hasn't been properly configured to make applications uses PA
   when available
3. The application is overriding the default.

in descending order of likelihood.

(The pulseaudio package sets the default by installing these
configuration files for ALSA:

    /usr/share/alsa/pulse-alsa.conf
    /usr/share/alsa/alsa.conf.d/pulse.conf

but those can be overridden elsewhere.)

Ben.
#821424#71
Date:
2016-04-20 03:58:36 UTC
From:
To:
Quoting Ben Hutchings (ben@decadent.org.uk):

.../...

Something like "not default installs" or "non default desktop
environments". Indeed, I have no precise idea, just somerthing along
"what would be the consequences of dropping these 'default groups' in
non default installs".

I'm all in for simplifying things and it"s very likely possible that
these things are just remains of the past, just as you own tests seem
to show.


So, well, are there any objections to us dropping all the above
groups from the list of groups the first created user is added to?
#821424#76
Date:
2016-04-20 09:20:46 UTC
From:
To:
On Tue, 2016-04-19 at 21:52 +0100, Ben Hutchings wrote:
[...]
[...]

The bluetooth group isn't used for device nodes (so far as I can see)
but in the bluez D-Bus policy (/etc/dbus-1/system.d/bluetooth.conf).
That also has an 'allow' rule for users currently logged in locally, so
again it's not necessary to add desktop users to the group.

Ben.
#821424#83
Date:
2018-01-30 18:32:26 UTC
From:
To:
Hi,

Please find attached an (untested) patch dropping the hardware access groups.


Saludos
#821424#88
Date:
2018-05-30 17:15:22 UTC
From:
To:
I have reposted the patch as merge request:
https://salsa.debian.org/installer-team/user-setup/merge_requests/1
#821424#93
Date:
2020-10-10 21:08:18 UTC
From:
To:
I've always found it bit weird and confusing that the first user
created during installation by d-i is "special" and belongs to a number
of groups that apparently are mostly unecessary in the modern world.

However, when you add a new user using the command line
(useradd/adduser), or the GNOME settings panel, the newly created user
does not belong to any additional groups, and still everything works
fine (except audio in fast-user-switching use case, if the primary user
is in the audio group).

Why should the first user be treated differently anyway? If some groups
are necessary for normal operation, shouldn't additional users also be
included by default? If the first user is considered the primary owner
of the computer and thus entitled to more permissions, that should be
at least clearly documented.

The merge request by Felipe Sateler removes most hardware access
groups, but still leaves three groups: dip, debian-tor and lpadmin. Is
the dip (dialup, ppp?) group relevant for most users? debian-tor is not
included in default /etc/group, but maybe it works if the user installs
tor from d-i?

The purpose of these groups and the access they grant to the user is
not clearly documented anywhere I could find. For example, the first
user is in the video group by default, and according to

https://wiki.debian.org/SystemGroups

"This group can be used locally to give a set of users access to a
video device (like the framebuffer, the videocard or a webcam)" What
does it mean in practical terms, if I can access /dev/fb0 and
/dev/dri/cardX? Can I snoop another user's screen while he is logged
in?
#821424#102
Date:
2025-04-14 10:27:33 UTC
From:
To:
I agree that discrepancy between user-setup and adduser is confusing and
should be eliminated.

I came across this bug when I noticed that the netdev group was
necessary to make network-manager-gnome working in stretch
<https://sources.debian.org/src/network-manager-applet/1.4.4-1%2Bdeb9u1/debian/network-manager-gnome.README.Debian/>
but since that time uaccess has made this group mostly unnecessary for
NetworkManager. It is used however along with sudo by polkit causing
difference related to creating of system-wide connections:

     nmcli general permissions

User created by installer:

     org.freedesktop.NetworkManager.settings.modify.system  yes

Users created by adduser

     org.freedesktop.NetworkManager.settings.modify.system  auth

In addition, I believe, user-setup and adduser should have consistent
behavior in respect to the "users" group (may be used to create
directories shared across local users).
I have no idea if another (remote) user can make a screenshot, but it
can use webcam. Udev and systemd-logind grant access to audio and video
devices for currently active local users through the uaccess feature, see
<https://bugs.debian.org/821424#61>
So membership in these groups is usually redundant and may cause issues
related to privacy.

I think, additional groups should be dropped and it should be announced
in a NEWS file and probably in release notes.