[pulseaudio-discuss] Accessing audio as root

[Markus Rechberger]

On Thu, Nov 26, 2009 at 10:31 PM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Markus Rechberger at 26/11/09 08:51 did gyre and gimble:
>>
>> Hi,
>>
>> I've been working quite a while with pulseaudio, one thing that breaks
>> alsa compatibility is that since PA is user based root is not allowed
>> to access audio.
>> This always worked with native Alsa even if root is not in the audio
>> group.
>>
>> I'm not sure if this behaviour is intended to be like that or if it
>> can be considered as an implementation bug...
>
> If becoming root under an X11 session, try "su" rather than "su -" when
> becoming root (or sudo -s vs. sudo -i). If you can access the X root window
> then the x11 properties will be readable by the root user and the
> PULSE_SERVER and PULSE_COOKIE variables will be all the root user (well
> libpulse really) will need to be able to access the user's PA process.
>
> When becoming root under X11, the "active" session as reported by
> ConsoleKit, still belongs to your user, not root, and PulseAudio honours
> this. That's why your root user should be talking ot your user's PA daemon.
>
> If you become root but do not have access ot the user's PA daemon, then you
> need to ensure you are doing so in a prescribed way. e.g. if you switch to
> VT1, then ConsoleKit should mark your users session as no longer "active"
> and PA will take this hint from ConsoleKit and suspend your user's access to
> the sound h/w. This then leaves the h/w free for the root user to access
> (either directly or by spawning his own PA (which is in itself probably not
> recommended - root users should not really be running apps that produce
> sounds anyway IMO - always remember that root is dangerous and should not be
> used for "desktop" things - sound output is something I personally classify
> as a "desktop thing").

this pretty much sounds like a workaround, but it still breaks the
behaviour of alsa without
pulseaudio - thus this is no good workaround...
We do reconfigure pulseaudio to run as system daemon our application
by default runs as
root. root should not get permission denied when he wants to play some
audio... (eg. when
logging in remotely as root).
I don't know how the permission stuff is handled, but root should be
an exception for this and
be allowed by default.

Markus