[pulseaudio-discuss] Accessing audio as root

[Markus Rechberger]

On Thu, Nov 26, 2009 at 11:15 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Markus Rechberger at 26/11/09 14:50 did gyre and gimble:
>>
>> I don't know how the permission stuff is handled, but root should be
>> an exception for this and
>> be allowed by default.
>
> The exception to the rule is not necessarily the problem (the concept itself
> is valid enough), but to think about this problem generally you need to
> understand how audio works and, more importantly, what are the underlying
> limitations.
>
> Firstly, PulseAudio handles software mixing for you. This is because most
> hardware does not support hardware mixing. This means that (at the lowest
> level) only one application is able to use the sound card at any given time.
> This clearly sucks, but obviously a software mixer solves this problem.
>
> Keeping in mind that the on a multi user system, the active user can flip
> around, with each real user being denied and allowed access to the audio
> hardware as appropriate, that it is not a nice idea to let root use the
> current active user's PA as this can change later, denying root the sound
> access by extension.
>
> So really there are only two solutions here:
>  1. Bypass pulse and access the audio directly.
>  2. Run roots very own PA process and use it.
>  3. Run system-wide PA.
>  4. Run PA on top of some lower level mixer e.g. dmix.
>
> Now all of these have major flaws and disadvantages. 1 and 2 require
> hardware mixing which is not all that common these days so is totally out of
> the question. 3. Is nasty, requiring access rules to be pushed into user
> administration (e.g. adding users to the pulse-access group)[0], and also
> breaking SHM usage in IPC which adds huge overhead. 4. Adds lots of latency
> and totally breaks glitch free control of the sound hardware which has huge
> knock on effects for power savings and other important aspects.
>

ok this sounds like PA breaks compatibility by design here...

> So really the problem is not all that simple. When considering all the
> various things that the old approach did not allow, but pulseaudio permits,
> this regression is really not a major one. Like I said previously you have
> to ask yourself some very serious questions when you are using a root
> process to interact with sound anyway? Why should any root process be doing
> that? Root is evil and should be avoided except when absolutely necessary.
> Added to that, the 99% use case of "root requireing sound" is while working
> under X11 and your regular user becomes root (su/sudo) to display a GUI app,
> sound will work just fine, so this is not a problem. The other marginal
> cases really don't present me with a burning problem that keeps me awake at
> night!
>

we could move it to kernelspace too it's a driver. please do not break
the default behaviour.
We already have some issues since the system structure is inconsistent
across most
distributions, but PA currently puts on a crown onto it.

we do not necessarily run X11 on our systems either.

If I'm logged in as root I'd like to have the control over the box
whatever happens.
So getting a permission denied from mplayer when playing audio is not
a good way to go,
especially since it worked with alsa and oss.
So it's 2 systems which worked for years against 1 system which caused
alot problems
during the last year, and those 2 somewhat 'mature' systems will
continue to work like that.
I haven't tried other Unix based systems yet but I do imagine that
other systems do work.
(eg OSX definitely works as root too!) The question should not be why
do you need it,
instead how can it be fixed...

Markus