[pulseaudio-discuss] Accessing audio as root

[Lennart Poettering]

On Wed, 23.12.09 13:16, Markus Rechberger (mrechberger at gmail.com) wrote:

> > 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.

Group-based access control is too limited for controlling access to
seats in a multi-session environment.  That's why we have extended
this with mechanisms like ConsoleKit and PolicyKit.

> 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.

I guess we have to agree to disagree here.

ConsoleKit (which is at the core of the multi-session support on our
desktops now, including in PA) has been designed 3 years ago and
pushed ino all distributions. It's the wrong time to whine about that
now, and to me. If you think the whole CK design is an abomination
then you are welcome to, but I'd prfer if you'd take that complains
somewhere else.

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

If you run things headless/in a server you have to configure
things. Surprise surprise...

Also, let me point out that dmix does not support simultaneous output
of streams from multiple users simultaneously either by default, for
security reasons. You can enable that, but you have to configure that
manually and it comes with a big yellow warning sign. This means that
PA and ALSA dmix are really not that different in this respect. PA
will make use of audio devices it has access to. ALSA dmix can do the
same. As long as one user accesses a PA device it is blocked for all
other users, which is very much like with ALSA dmix. The only
difference is that on ALSA dmix after the user stopped using the
device it is immediately accessible to othre users again, while in PA
there is a 1s timeout. Not that big a difference.

I'd prefer if you'd get your facts right before you start whining.

> 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 dont force anything. It's Free Software. Take it or leave it. If you
don't like it then you are entitled to that, but I find it kinda
annoying if you then whine on our mailing lists, and start demanding
things. That's not how it works. I am interested in constructive
feedback but not at all being accused of "forcing". And if we disagree
on something then please accept that. I have explained why we do
things the way we do. And unless you have a better approach and some
code to show I am pretty good at simply going on with what I do.

> 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

Did you read any of the emails I wrote in this thread?

if not, try it!

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4