[pulseaudio-discuss] Accessing audio as root

[Markus Rechberger]

On Wed, Dec 23, 2009 at 12:57 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Tue, 22.12.09 17:54, Markus Rechberger (mrechberger at gmail.com) wrote:
>
>> >> Well, but nevertheless an X session is required to allow differend user
>> >> accounts to access the audio subsystem at the same time. This is a
>> >> drawback for me as I'm used to do a lot of my daily work on a text
>> >> console outside of a X session, so I need to run X just to share audio
>> >> access between different user accounts.
>> >
>> > This is a bit confused.
>> >
>> > PA does indeed *not* allow multiple users simultaneous access to the
>> > same audio device. This is because we consider the sound card to be
>> > part of the user seat,
>>
>> And this is the problem because it works with alsa, simply add every
>> user you want to give audio access to the audio group and it worked.
>> Even with OSS this worked. But PA breaks this behaviour.
>
> First of all, we broke exactly nothing. You can always bypass PA and do
> stuff like this.
>
> Secondly, allowing access to the audio device to all users is a
> security hole as I tried to explain quite a few times. Allowing that
> means a user can evesdrop into your voip calls, he can even completely
> monitor whatever you say when you sit in front of your computer. You
> don't allow access to your kbd and screen to all users either,
> right? it was a security issue that has been open for a long long time
> that access to audio devices was not regulated the same way as acess
> to your kbd and screen. We fixed that. Just because something works
> differently than it worked before it doesn't mean it's broken.
>
>> How about I set up an FM Radio server, there's a daemon process
>> accessible through a website which runs either as root or as his own
>> dedicated audio user - there we already have our use case.
>
> If you use a server-like setup, i.e. a headless machine without local
> sessions, then use system mode of PA. (or bypass PA)
>
>> I can even imagine that with OSX it does not cause any issue to log in
>> from a remote host and play some audio.
>
> Actually OSX does exactly the same thing when you switch between
> sessions: it stops output from one session and enables output on the
> other. Mentioning OSX as an example here is really something that
> can only backfire...
>
> Also, as Colin pointed out SSH logins certainly want audio output on
> the terminal side, not the server side.
>
>> Please just fix this.
>
> There is nothing to "fix".
>
>> > the same way as the keyboard, the mouse, or the
>> > screen. If we'd allow multiple users access then they might eavesdrop
>> > into your voip calls or even record anything you say from the mic. As
>> > long as a user is active on a seat he should be the only one who has
>> > access to its devices.
>> >
>>
>> I don't think it's innovative to cut the possibilities back we had
>> before, it should be up to the user what he wants to do and what not.
>
> Right. It is innovative to carry on with the brokeness we always had
> just because we always had it and not because we would ever think
> about the brokeness and fix it? Is that what you think?
>

Right, we had /etc/group for setting up the permissions pulseaudio breaks this
behaviour even with the Alsa compat library.

> Also, the same discussion we already had 2 years ago on fedora-devel
> and other mailing lists. Kinda pointless bringing this up again and
> again and again.
>

Sorry this behaviour is just broken, Pulseaudio should not be part of
any distribution
until a certain level of compatibility is reached.
compiz is optional it's easily possible to enable or disable it.

The recommendation to use system mode is also a failure, why should
someone reconfigure
the entire audio system on a distribution?

We have deployed alot devices which depend on audio nowadays at
certain b2b customers,
guess how many are using pulseaudio? -- exactly noone. After talking
to engineers everyone
feels like PA is just a pain, and by forcing your ideas which break
the default behaviour
this situation will not improve.

I'd rather like to see a clear statement why it is currently not
working, so someone can get
onto that topic and fix it. If you want to block it for other users
add a configuration option for it
but again don't break the default behaviour

Markus