Reference from Ubuntu wiki on the arguments against using audio group
as default for users https://wiki.ubuntu.com/Audio/TheAudioGroup.

audio group is currently expected by the jackd packages to gain
realtime privilege for users. jackd1 and jackd2 packages install
the file /etc/security/limits.d/audio.conf for this purpose.
It is also required to gain acess for a set of firewire devices
using the ffado driver. Privileges granted with the file
/lib/udev/rules.d/60-ffado.rules installed by the package libffado2.

I propose to remove audio group from the list of user default groups
and add a new one for jack, specifically.
Either named "jack", or as is praxis on Fedora systems, "jackuser".

In any case, it would be good to standardize the group for jack. The
use of such a group for jack is the much preferred option. It is what
jack devs recommend, and it is the way most people use to get realtime
privilege.

Sorry, this is not Ubuntu, so their policy does not apply.
Feel free toraise this topic on a mailing list instead.

Kaj Ailomaa wrote:

Hi.

On closing the bug report. What is the Debian policy on the usage of
audio group exactly? I have been unable to find anything in writing.
And, I did not want to impose a Ubuntu policy. I was just referring to
the information on the wiki page for reasons to not use audio group for
users, while putting up the question whether should Debian use it or
not.

Also, since audio group is also used for realtime privilege (which is
not really related to audio directly), perhaps the reasons for using the
group would need to be examined, as well as determining whether it would
be better to use another group for jack.

I did start a discussion on debian-devel about this.

I would also like to emphasize that this is an important issue for a
great many users, and that a better policy on using the jack server
could have a lot of positive effects on the entire Linux audio world in
the longer perspective. This is also the main reason for my bug report.

Cheers

reopen 766914
reassign 766914 user-setup

Hi,

I'm reopening this bug as to Marco's reply on -devel sounded like we should
improve audio permissions for users in jessie+1, and this seems to be like a
good tracking bug. I'll bounce some mails from -devel to this bug shortly.


cheers,
	Holger

Yes.
Debian users should not be in the audio group: if the devices are not
already covered by the rules in /lib/udev/rules.d/71-seat.rules then
they should be tagged with TAG+="seat" so that users on the local
consoles will be able to access them..
I see no obvious downsides.

Eventually, yes.
Actually the correct tag is uaccess, and
/lib/udev/rules.d/70-uaccess.rules will already do it for you for all
ID_FFADO devices.

Debian Bug Tracking System wrote:

Thanks for assigning this bug to the right package.

Hello,

I had #849265 reported against adduser for this problem that exists in
d-i's user-setup. It also exists in adduser if the --add_extra_groups
flags is used (which is why I didn't reassign/merge), user-setup is
adding this groups directly.

See the bug log for 849265 [1], as well as my correspondence with
pkg-systemd [2].

Thanks and regards
Afif

1. http://bugs.debian.org/849265
2.
http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2017-January/013684.html

Dear Customer,



This is to confirm that your item has been shipped at January 15.



Download postal receipt attached to e-mail!



Sincerely,

Willard Boyle,

USPS Parcels Delivery Manager.

Hi,

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


Saludos

I have reposted the patch as merge request:
https://salsa.debian.org/installer-team/user-setup/merge_requests/1

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?

jftr, adduser is going to reduce its EXTRA_GROUPS default to "users"
with the next release, 3.122

Greetings
Marc

On Wed, 30 May 2018 13:15:22 -0400 Felipe Sateler <fsateler@debian.org>
wrote:
 > On Tue, Jan 30, 2018 at 3:32 PM Felipe Sateler <fsateler@debian.org>
wrote:

Hello,

 > I have reposted the patch as merge request:
 > https://salsa.debian.org/installer-team/user-setup/merge_requests/1

Now that we are early in a new development cycle, could we consider such
patch?

That should obviously be documented in the Release Notes

Kind regards,

Laurent Bigonville