[pulseaudio-discuss] Multiple users (kde) on Debian

[Colin Guthrie]

'Twas brillig, and Mark Cross at 26/07/10 15:23 did gyre and gimble:
> Colin Guthrie wrote:
>> But ultimately you can run PA in system mode. Lots of things don't work
>> as nicely (such as module loading and such like) and efficiency
>> mechanisms (i.e. using SHM for data passing which is much faster) will
>> be lost.
> 
> Yes, I am aware of that option. However, on reading this:
> 	http://pulseaudio.org/wiki/WhatIsWrongWithSystemMode
> 
> One gets very discouraged to do so. For example:
>     "  Security: all users that have access to the server can sniff
>        into each others audio streams, listen to their mikes, and so on.  "
> 
> And, in particular:
>     " You are using PA against the explicit recommendations of the
>       maintainers, so don't expect particularly enthusiastic support
>       from them in doing so. "
> 
> Which essentially says: "You are on your own". Having to cope (even more) 
> with each change on the sound system, or HAL, or Policy-kit, because this 
> is a not "supported option" is not an interesting future.

Indeed, for the reasons listed it's not exactly ideal.

> So, there must be a way "supported by maintainers" to have two PA instances 
> form two users that share access to the sound system.

Sadly there is no officially recommended way to do this. This is
actually enforced at a lower level than PA with ConsoleKit ultimately
being responsible for writing the ACLs on the device nodes (via udev)
used for the sound h/w.

ck-list-sessions will tell you which user is "active" and typically this
user will get access to various different resources on the machine by
virtue of them being active.

PA simply listens to messages from CK and gracefully releases it's
control of the devices when it's not supposed to have access. In reality
we're just being a good citizen in this regard.

> The problem Pulseaudio was supposed to solve was to have mixing of several 
> streams, but in doing so, PA took total ownership of the sound hardware, 
> not allowing any other service to access the hardware, not even a second 
> instance of PA. That have just shift the mixing issue from ALSA to PA, with 
> seemingly equivalent basic problems. Yes, it has several interesting and 
> useful features, but I wonder: what is the "supported" way to have several 
> services access the sound system?
> 
> As the developers decided to completely take ownership of the sound 
> hardware:
> 
> Shouldn't exist an option like: [ xhost +local:user2 (X-server) ] for PA?

In theory this would be possible. There are however two basic problems.
The first is that a physical socket file patch is currently used. This
could be changed perhaps to be a more abstract socket, but as things
stand, user2 would need to have physical write permission to that socket
(there are various ownership checks and such in the code).

But if user2 could access user1's PA socket, and he had access to the
"cookie" used (~/user1/.pulse-cookie), then user2 could output sound to
user1's PA daemon.

If user1 were a member of the audio group, then even if user1's session
was not active (according to console-kit), he would be allowed to access
the sound devices by virtual of them being group writeable.

A perhaps simpler (and slightly less efficient) mechanism to enable this
is to simply enable networking support for the primary user (either
without authentication or with a copied cookie file). Then set
"default-server=localhost" in the client.conf of other users.


Of course the same problems regarding the ability of user2 to know what
output user1 was making and generally sniff or otherwise interfere with
them still exist (and user2 would also not be able to use SHM etc. too).


I think a pahost +.... syntax would be nice, but it's not something that
is currently possible OOTB due to the way in which PA follows the
'active' user around.

Also most people expect to get exclusive access ot the sound h/w when
switching users (it's how it works on Windows and Mac OS) and that is
therefore the case we really want to get right, even if other, more
exotic, scenarios are not easy to achieve.


Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mandriva Linux Contributor [http://www.mandriva.com/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]