[pulseaudio-discuss] Accessing audio as root

[Markus Rechberger]

On Wed, Dec 23, 2009 at 1:16 PM, Markus Rechberger
<mrechberger at gmail.com> wrote:
> 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
>

Just to add, we do not depend on such changes anymore since we suid over to
the current running pulseaudio user.
But to add some more usecases skeem freshmeat.net and write up a list of how
many audio projects you are breaking (because there are quite a few ones who run
as daemon).

Markus