[pulseaudio-discuss] Uber-early glitch-free Testing Results

Lennart Poettering lennart at poettering.net
Mon May 5 16:40:08 PDT 2008

On Wed, 16.04.08 16:13, Sean McNamara (smcnam at gmail.com) wrote:

>     * PA should not run with --system (as 'pulse' user) because you
> can't use SHM transfer, you have to tweak PolicyKit to allow real-time
> scheduling to the 'pulse' user, and because you have to add all
> desired users (of the -unix protocols) to the 'pulse-access' group.

I guess packagers should simply add the "pulse" user to the "pulse-rt"
group by default, if they ship support for system mode.

> who want access when the user logs off. Test it: start pa with
> --daemonize=true and as a regular user, then log off the session.
> Poof, PA gone.

Nah. That's not true. It might be that you the X11 modules
loaded. libX11 has this annoying behaviour of terminating the
application if the X connection ends. If you don't load those modules
(or if you unload them before detaching) PA should stay running.

> So it seems the 'pulse' user needs to be *made* to be able to use shm
> ;-) Is there any way to feasibly do that?

Oh, SHM support in system-mode PA is disabled because I added specific
code to disable it. If you drop that check PA is perfectly able to do
SHM in system mode.

The thing is simply that SHM exposes far too much information about
PA's internal memory management to other processes. Funneling
everything through a single kernel-controlled socket is good security
gateway if you want to speak with processes you don't trust. Far
better then giving them access to all your internal memory management
data and more.


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

More information about the pulseaudio-discuss mailing list