On 03/12/14 14:28, Bjørn Mork wrote:
> Josselin Mouette <j...@debian.org> writes:
>> We are talking about the anti-feature of adding UID=1000 to the audio
>> group in the installer.
>
> Are we? I was talking about making audio work for the first-user. I
> see that as a feature.
It's a trade-off between utility and privacy: a feature and an
anti-feature at the same time.
Feature 1: users who log in locally via a getty or any desktop task's
*dm [1] can play and record audio [2]. You get this either way, because
logind (or, historically, ConsoleKit) provides it. This provides the
reasonable expectation that a user who is physically sitting at the
machine can record anything that they, themselves, can hear, and can
control what comes out of its speakers.
Feature 2: if the first user created via the installer logs in via a
non-local mechanism (typically ssh) [3], they can still play and record
audio. If you expect that the first user created via the installer is
special, then this might be a reasonable expectation; I personally tend
to agree with Josselin's assertion that if you want a headless/"daemon"
user to be able to use audio, that's a logical part of the special setup
that you are going to have to do for that user in any case.
Anti-feature 3: while a second user is logged in, the first user can log
in via ssh or whatever, turn on the microphone and listen to the second
user, violating reasonable privacy expectations (and, less important,
the first user can annoy the second by playing loud sounds or Rick
Astley or whatever).
Feature 2 and anti-feature 3 directly contradict each other. You can
have one or the other, but not both. Josselin argues that the absence of
anti-feature 3 is more important than the presence of feature 2 [4]; you
argue the opposite.
At one extreme, you could say that audio devices should be chmod'd 666
because "it just works"/ease-of-use/minimal setup is a good thing; and
at the other extreme, you could say that audio devices should be
root-only by default. You have different preferred points on the
spectrum of reasonable compromises between those ridiculous extremes.
S
[1] possibly only if you have the recommended packages for a task,
but we recommend things for a reason
[2] in single-seat setups; in multi-seat setups, anyone logging in
at a particular seat only gets the audio devices (and USB ports,
etc.), if any, that are associated with that seat
[3] or at a different seat, in a multi-seat setup
[4] perhaps because his perceived utility for feature 2 is zero
--
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/547f2787....@debian.org
