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

[Colin Guthrie]

'Twas brillig, and Mark Cross at 26/07/10 18:05 did gyre and gimble:
>>> 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.
> 
> We are talking of two instances of PA here, saying that the responsibility
> is somewhere else (in CK), looks like a way to squirrel away the
> responsibility to do the "right thing". If user1 "validates" access to
> user2 (pahost + concept), what's the fuss?

If it's squrreling out then I apologise, but really different components
of a system should work together right? Different layers should
generally be interoperable right? Or should every layer just do it's own
thing and screw the decisions and designs of lower layers?

That said, I'm certainly not against the principle of a validation, but
that is fundamentally different to the whole design of PA as it stands.
The concept may sound simple, but it'll basically require a full rewrite
of large parts of PA, not to mention changing several parts of
consolekit and udev with regards to the ACLs.

>> 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.
> 
> Hmmm, yes that is working. On user2 logging-in and getting it's "Session"
> as active, is able to play sounds. On switching with CTRL-ALT-F7 and CTRL-
> ALT-F8 (or using switch-user) the corresponding "Session" changes state to
> active and is allowed to play sounds.
> 
> However, this concept of "active" deals with the logged-in user, there is
> no "concurrency" in it. Each user is switched "on" or "off" as needed.

That's the way it works yes. If you don't like this approach it's really
something to bring up with the Console Kit folks and make your case there.

>> 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.
> 
> Yes, PA should acknowledge CK messages and act accordingly. I don't know if
> "demanding" "exclusive, unchallenged" "ownership" of the sound hardware is
> being a "good citizen".

Well all we're doing is acting on the messages given from a lower layer
in the system. I'm not really sure how we can do more than that.

>>> 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.
> 
> Linking the "cookie" (~/user1/.pulse-cookie) is easy enough, what else is
> needed to "access user1's PA socket"?

Well it's just a matter of getting the path correct. On a typical X11
login, have a look at the output of "xprop -root | grep PULSE" this will
show you the format of the PULSE_SERVER variable. This can be put into
the env var PULSE_SERVER or the client.conf file as the default-server
option.

>> 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.
> 
> Not having any user as part of the "audio" group is a PA recommendation:
> 	http://pulseaudio.org/wiki/FAQ
> 
>     Section 3 - Troubleshooting,
>     Item 10 Sound doesn't work when switching users
>      "  By removing all users from the "audio" group (the PulseAudio server
>         still runs in the "audio" group), PulseAudio is able manage access
>         to sound devices (/dev/snd/*) amongst multiple users with the help
>         of ConsoleKit.  "
> 
> That enforces the concept of PA being the owner of (/dev/snd/*), so, it
> should be PA who should deal with this "concurrent" situation IMO.
> 
> Also, "audio" group ownership creates this kind of problems:
> 	http://swiss.ubuntuforums.org/showthread.php?t=1417647&page=2

Yes it is indeed the part of the recommended set up, but then so is the
method of operating where only the active user has access to the sound
system and you've already stated that you don't accept that
recommendation so it follows that you may also have to deviate in other
ways too.

Also I don't think, that "PA being the owner of /dev/snd/* is correct. I
will try and update that FAQ to clarify, but the PA server does *not*
run in the "audio" group as quoted. It runs as the user, and consolekit
gives the active user write permission on /dev/snd/* by virtual of an
ACL. The audio group does not come into it.

Only when PA is run as a system service would the "pulse" user have to
be in the "audio" group. On a typical setup, this would not be the case.

So PA really is not the owner of /dev/snd/*. It merely listens to what
consolekit and udev say and adheres to it.

>> 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.
> 
> No, that will create this "rather confusing situation occurs":
> http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg06635.html
> 
> So, using such option breaks normal "user switching".

But you don't *want* normal user switching.... Have I completely missed
the point? I'm confused why you bring up this "disadvantage" when in
actual fact you really want to exploit this behaviour to get concurrent
access.


>> 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 rather see this "sniffing" issue rather "inconsequential" IF user1
> specifically has to validate user2 access. After that, user1 will know,
> as he has enabled such access.

Yeah, that's a valid argument. If the the user has allowed access then
they've allowed access and anything that happens, happens with their
tacit agreement (tho' me agreeing with the principle, doesn't change the
fact that creating such a system would require a significant amount of
reworking of design and code of various Linux subsystem all for the 10
users who have ever moaned about this!).

> Besides, what is the issue with the output? Having the sound of a
> "Brittany Spears song" playing in the speakers is so annoying?
> Doesn't PA have the ability to mute individual streams?
> Just present user1 the running streams of user2 in pavucontrol and allow
> him to mute as needed.
> 
> The only (remote) issue is with grabbing the "mic", which user1 has to enable.
> But, there isn't the ability to control individual recording streams in
> pavucontrol as well?
> 
> Just do the opposite, mute by default, and allow user1 to unmute as needed/desired.

Such suggestions mean that a large chunk of PA would need to be
rewritten to include a concept of "users" with different policy on
modules/clients/sources/sinks/sink-inputs/source-outputs etc. depending
on the active user as indicated by console kit.

Such a design could work (there are numerous problems and caveats and
reasons not to do this but I wont go into the detail here), but it's a
massive project, and I very much doubt anyone here will be working on
something like that any time soon.

>> 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.
> 
> Yes, it would be a good thing to implement.

As I said above, as much as this is a nice thing to implement, it would
require a significant rewrite of a large chunk of PA.

>> 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.
> 
> Gee, following the "lead" of Windows, which wants only one user to use
> the computer to make sure each user pays for the software, doesn't seem
> the right "recipe" to apply to a multiuser Linux system.


I find it highly bizarre that people automatically assume that just
because windows does something, that it's wrong. So many linuxy people
do this and to do so automatically is arrogant in the extreme (not
suggesting this is the case here tho'). I'm as happy as the next linux
geek to bash windows, but I'm no so crazy as to assume that everything
on windows is automatically "wrong" regardless of how much I may
disagree with certain other aspects.

The fact of the matter remains that user switching is something that
Linux has done for a long time, but so has Windows and OSX and more or
less they've all behaved in the same kinda way: by making the crazy and
outlandish assumption that the user sitting at the keyboard and looking
at the monitor is the one that should have full access to the machine's
resources. Is that really such a crazy concept? Sure there *can* be
multiple users who want to use the devices at the same time, but this
use case is a tiny fraction of the percentage of the overall audience.
Things *can* currently be made to work the way you want it, but we very
much focus on the common case. Is that really such a bad idea?

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/]