PulseAudio

[David Zeuthen]

On Tue, 2007-02-27 at 15:44 -0500, xiphmont at xiph.org wrote:
> On 2/27/07, William Jon McCann <mccann at jhu.edu> wrote:
> > Hi Monty,
> >
> > On 2/27/07, xiphmont at xiph.org <xiphmont at xiph.org> wrote:
> > > An earlier question still stands, and it is central: does UID ==
> > > console session ID?
> >
> > To me, this is very much like asking "Does UID == $DISPLAY"?  And the
> > answer of course is - not in general.
> 
> I am asking so that the answer is a documented-- and thought about--
> instead of being a nebulous assumption.  For one, it will be difficult
> to have true session-unique emulation support because those interfaces
> used /dev permissions with no concept of session, only uid and gid.

If the emu system daemon runs as root you, then /dev/dsp and friends
would only need to be accessible by root assuming the emu system daemon
passes the fd to the PA instances. 

That's what I meant in the other mail with:

> It's fine being a system daemon if it's a pure mechanism. Tell me,
> said emu system daemon knows the uid/pid of the opener of the device.
> Presumably this emu system daemon would pass the file descriptor to
> the appropriate PA instance. How about that? (I tried to ask a few
> times but you never really answered)

In order to identify the correct PA session instance you would look at
$XDG_SESSION_COOKIE in the environment (/proc/pid/environ) for the
caller. Or, more portable, make a D-Bus call to ConsoleKit to get this
given the pid.

Of course, this means that PA needs to be changed to name it's sockets
using the Session name (not the cookie!) instead of the username. But
that change is easy. And for now GNOME (probably not KDE either) support
multiple logins by the same user on the same box. But that's something
we want to fix eventually.

Hope this helps.

    David