* Simon McVittie <smcv@debian.org> [141110 00:55]: > 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. I fully agree; it's just that the audio group can't just vanish. > 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: > [..] I vaguely remember PolicyKit being involved in the daemon situation, when mpd tries to talk to a pulseaudio server which magically gets spawned ... I'll probably just have to figure out the details again when any of the moving bits change. Cheers, -- ,''`. Christian Hofstaedtler <zeha@debian.org> : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `-
Attachment:
pgp2aqGvVwfzA.pgp
Description: PGP signature