On 09/11/14 23:34, Christian Hofstaedtler wrote:
>>> On the other hand, it would break typical uses of using sound remotely.
>>
>> This usually happens via UPnP or similar, though - the actual audio is
>> ultimately done by a local user. So the audio group is unrelated to this
>> usecase.
>
> It very much is, because those users are usually daemon users that
> are not logged in through a session manager, and thereby don't get
> access granted by PolicyKit (or equiv).
Fine, put those daemon users in the audio group - in their packages'
postinst scripts, if necessary. I'm not saying that the audio group
should be abolished, only that "normal user" accounts (as created by
d-i, gnome-control-center, etc.) should ideally not be members of it.
FYI, PolicyKit is not actually relevant here: the actual access control
for (most uses of) the audio group is done by the kernel, when an
application running as the target user (often something like PulseAudio
or JACK, rather than the actual user-facing application) tries to open
the audio device nodes. systemd-logind implements "locally-logged-in
users may use audio devices" by setting ACLs on the device nodes for
those users:
% getfacl /dev/snd/pcmC0D0p
getfacl: Removing leading '/' from absolute path names
# file: dev/snd/pcmC0D0p
# owner: root
# group: audio
user::rw-
user:smcv:rw-
group::rw-
mask::rw-
other::---
(In this case, smcv is the only locally-logged-in user.)
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/545ffecd.4050...@debian.org
