Running PulseAudio as System-Wide Daemon

Starting with PulseAudio 0.9.3 the daemon can be run as a system-wide instance which than can be shared by multiple local users. We recommend running the PulseAudio daemon per-user, just like the traditional ESD sound daemon. In some situations however, such as systems where multiple users are logged in at the same time, or embedded systems where no real notion of a user exists, it makes sense to use the system-wide mode.

To run PulseAudio in system-wide mode, start it as root and pass the --system argument to it. It will then drop priviliges and change to the pulse UNIX user and group. The directory /var/run/pulse/ is used as home directory. In this mode the module module-native-protocol-unix will automatically allow access to all members of the group pulse-access. All user/group names and paths can be changed by passing compile-time arguments to configure. The system user pulse and the groups pulse and pulse-access need to be created manually. On Debian this works like this:

addgroup --system pulse
adduser --system --ingroup pulse --home /var/run/pulse pulse
addgroup --system pulse-access

# Some distributions restrict access to the sound devices to a group audio
adduser pulse audio

# Add a user to the pulse-access group
adduser lennart pulse-access

The runtime directory /var/run/pulse is created automatically on daemon startup. This directory contains the .esd_auth file, which is the authentication cookie for esound. If you want to use esound without disabling authentication, create a symlink from this file in your home directory:

ln -sf /var/run/pulse/.esd_auth ~/.esd_auth

Please note that creating these groups/users is not necessary when running the PulseAudio in the traditional per-user setup

Running PulseAudio in system-wide mode has some limitations:

• All users with access to the sound server cann kill/modify all sinks/sources and streams of all other connected clients
• There is only a single namespace for cached sound samples, i.e. there can be only a single Gnome event sound profile active at the same time

It has some advantages over the per-user setup:

• Multiple local users can share the same instance
• Better security, because the daemon runs under its own user/group, seperate from normal users

It has some disadvantages:

• Worse security, because the user can now command a server app running under another user name. He could even load/unload modules from that sound server
• Settings like the stored volume levels managed by module-volume-restore are no longer per-user but system-wide

If the system-wide mode is enabled it is advisable to disable module loading during runtime by passing --disallow-module-loading to the daemon, to inhibit the user from loading arbitrary modules with potentially vulnerable code into the daemon. However, this might break some modules like module-hal-detect which will load a sound driver module each time HAL signals that a new sound card became available in the system.