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

[Colin Guthrie]

'Twas brillig, and Mark Cross at 26/07/10 22:57 did gyre and gimble:
> Colin Guthrie wrote:
> 
>> 'Twas brillig, and Mark Cross at 26/07/10 18:05 did gyre and gimble:
> 
>> 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.
> 
> Then, perhaps, the design is flawed from the beginning?

I don't think so. To do something as you suggest essentially means that
a whole user-based permissions model has to be built into PA and PA
itself has to be turned into a system service. This in itself means that
lots of nice things like the zero copy core will have to be sacrificed
because the overhead of secure SHM access across users is likely to not
be worth the benefit.

In other words the whole user-based principles of a unix based system
are essentially thrown away and a whole new user-based system is built
into the sound server subsystem. This isn't the right place for a user
management system in the first place and it doesn't make sense really to
implement it there.

Just because the system does not do what you want it to do, does not
mean that:
 a) There are not good reasons against doing what you want.
 b) That the design is flawed.

You're perfectly within your rights to ask the question, but I happen to
think that the design is not flawed, and it's simply a use case that,
while attractive to some niche use cases, has implementation
repercussions that are a long way from desirable.

>> 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.
> 
> I really don't know the details, but:
> 
> Is CK controlling the (xhost +...) made by the X-server?
> Or is it a service/task that the server covers by itself?

No but CK will control access to e.g. /dev/dri which is used by the
xserver. It has nothing to do with the permission to access the X server
socket and the right to use the Xserver. In actual fact the X server
case is a pretty good example of what we do. We are very similar to the
X server. I'll describe it below.

>> 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.
> 
> No result from that command here:
>      $ xprop -root PULSE
>      PULSE:  no such atom on any window.
>      $ xprop -root | grep PULSE
>      $
>      $ _

I guess you've either a) restarted PA since logging in to X11, or b) do
not have an XDG compliant login manager that processes XDG autostart
.desktop files.

The file start-pulseaudio-x11 should be run via XDG autostart at X11
init. This script will make these properties available. These properties
allow you e.g. to ssh to a remote machine and have the display *and* the
sound locally.


>> 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.
> 
> Why, oh my, why, such answer?

I thought it was a perfectly reasonable answer? I'm not suggesting there
is anything particularly wrong with your approach. It's not the typical
use case but the software can do it and I'm trying my best to tell you
how to use it that way.

> It isn't anything to do with what I accept or not. I am trying (very hard) 
> to comply with all the pulseaudio recommendations and "special" conditions 
> and, at the same time, cover a simple, specific need. One that seems 
> impossible to get you to agree exists, much less provide a solution to.

Sorry you feel that way. I've tried my best to describe what you need to
do to get it working. If those instructions are not clear then please
let me know which bits you are having trouble understanding.

You are correct that I don't agree that your use case is one which has
any real life, practical uses, but I've certainly given you a two or
three different ways in which you can achieve the end result you want.

The fact is that your "simple, specific need" is orthogonal to the
"special" conditions. You can't have both at the same time. If you can't
sacrifice the special conditions, then you have to give up on achieving
your solution.

>> 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.
> 
> That's what the pulseaudio.org FAQ says, no my fault in any way.

I never implied that it was. I even said I'd try and find time to update
the FAQ, so quite clearly implied that it was wrong, not you.

>> 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.
> 
> The system service is something you "strongly discourage".

Yes I do, but if you want to get the result you asked for it's one of
the possible solutions. Would you prefer that I'd simply replied to your
thread and said, "sorry you can't do that" and ended it there, or is it
actually OK for me to try and suggest approaches and configurations that
will get you the setup you want? I kinda presumed the latter was the
right approach.

>> So PA really is not the owner of /dev/snd/*. It merely listens to what
>> consolekit and udev say and adheres to it.
> 
> So does the X-server, I presume, and yet they have the (xhost +...) option.

OK, so here is my Xserver analogy.

The user who is active has the display in front of them and can see
their applications right?

If another user is permitted access to the xserver, that user (even if
they are not the "active" user in consolekit, can run their app and have
it appear on User A's display right?

But if User A becomes inactive and, say, user C logs in. What happens to
users A and B? Their applications can still run, and they can still
produce their GUI, but you can't see it because the physical display is
busy dealing with user C's desktop and applications.

Everything in user A and B's world proceeds as normal (tho' maybe not GL
applications which need DRI access), but they are essentially invisible.

Well this is *exactly* the same as pulse and the sound card. If user B
were able to access User A's pulseaudio server, it would still only be
consumale (generic term meaning visible for X and audible for pulse)
when user A is "active".

So really the whole xhost + command does not solve your problem. It
merely deals with an authentication of one user to another's PA daemon.
It doesn't handle whether that PA daemon itself has the rights to use
the audio device. Just like with /dev/dri, access to /dev/snd/* is
controlled via the ACLs set by consolekit and udev. It's actually no
different.

>>> 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.
> 
> Why I don't *want* normal user switching? Perhaps I am not in your set of 
> "pre-analyzed groups"?

Normal user switching means that the active user has access to the
machines resources. If you don't want that approach then good on you,
I'm not trying to stop you, but please appreciate that this is deviating
from the normal case. I'm trying my damnedest to tell you how to do it
but you keep trying to shoot down my suggestions saying that because
it's not part of the recommended setup then I shouldn't recommend it.
Not quite sure what else I can do other than to just lie to you tell you
"it can't be done"...

> Let's accept the concept that this is a computer in which several users 
> work, not much, but they have accounts and use when needed. Being that the 
> case, switching accounts and having sound work on each account is welcomed, 
> and accepted as how "things should be". Having all users share the same 
> pool of resources is not "a wise thing to do", as, even if I trust most of 
> the users (to a certain extent), there is no guarantee that they will not 
> do something foolish. Not that they will be "evil", just dumb sometimes.
> 
> Then, this "small" issue of a flash bug appeared. Flash "upgraded" to 
> version 10, but in the process, left out 64 bit support. This system, 
> sadly?, is a 64 bit system. So the options were: live with the security 
> flash bug, use nsplugin, or create a 32 bit chroot. Leaving the system for 
> all users with a "open hole" is out of the question. The nsplugin is a 
> sorry mess now, changes all the ia32libs to get "almost" working. So, the 
> only viable solution was to use a chroot setup.
> 
> Having the undesired task of setting a chroot 32 bit for flash, I decided, 
> well, then, let's get the browser out of any access to the local user files 
> and rights, let's use a different "user account" for the browser.
> 
> Here is where I am getting to this brick wall of "not possible" to share 
> sound between users with PA.
> 
> Well, really, to several possible solutions, none of which seems to be the 
> "right one".
> 
> Perhaps I have to re-think all this over *again* .

You should perhaps have explained this initially. This is a very simple
setup and one that the start-pulseaudio-x11 script I mentioned above
makes more or less automatic.

Pulseaudio can store various configuration variables as properties of
the root X11 window. Clearly the browser (running as another user) will
have access to the X11 root window. In that case the browser will have
access to the properties that pulse has set.

If start-pulseaudio-x11 has been run then:
 xprop -root | grep PULSE
will return some results.

e.g. here is says:
PULSE_COOKIE(STRING) = "LOTS OF TEXT HERE"
PULSE_SERVER(STRING) =
"{6cb2a4b2bd6df042e57dablah}unix:/home/colin/.pulse/6cb2a4b2bd6df042e57dablah-runtime/native
tcp:jimmy:4713 tcp6:jimmy:4713"
PULSE_SESSION_ID(STRING) =
"6cb2a4b2bd6df042e57dablah-1280059215.515847-2115367457"
PULSE_ID(STRING) = "603 at 6cb2a4b2bd6df042e57dablah/31539"

These are all the details needed for a given user to connect to my
Pulse. Provided that user can access my socket path
(/home/colin/.pulse/6cb2a4b2bd6df042e57dablah-runtime/native) at a
filesystem level, then all will be well. The cookie string will be used
to authenticate that user and sound will "just work".

I've used this approach several times and you should be able to get it
to work without much trouble 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!).
> 
> There goes again: I am one of 10 users who ever "moaned", thanks!!.

What's wrong with moaning? I do it all the time about things I don't
like and want to change.

> Perhaps the rest of users just haven't realize they have such need, yet.
> 
> Or you are just: "not prepared" to deal with this reality?

There is simply not the need to do what you want. There are often other
solutions to the problems you present and the fact is I've detailed
three that would work fine. Suggestion number 2 is likely the right one
for your scenario, but utilising the X11 properties for user B's access
rather than manual configuration.

Personally, I don't think running the browser as a separate user is
necessary and think it would save a lot of hassle to simply not bother.
I run a 64 bit system and have a several 32 bit programs installed,
including web browsers without the need for any chroots. I thought all
modern distros managed to split out 32 and 64 bit libraries into a)
different file paths (i.e. /usr/lib vs. /usr/lib64) and different
packages (e.g. lib64pulseaudio0-0.9.21-27mdv2011.0.x86_64.rpm vs.
libpulseaudio0-0.9.21-27mdv2011.0.i586.rpm) to allow for simple
concurrent and non-conflicting installs? If not, then complain to your
distro as this seems like a lot of work to put into something that
should just work fine (and does for me in my distro).



>>>> 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.
> 
> Were did I "Automatically assumed"?

You didn't. I said very clearly above that I was not suggesting that
this was the case here. Consider it a general purpose rant.

> Not having the capability for several users to access the graphical screen 
> (X-server) is a Windows limitation, much alike as not having access to the 
> sound system for several users.
> 
> I am very sorry you fail to realize that.

But only one user can *see* the screen at once. So why is it so
unreasonable that only one user can *hear* the sound at once. Having
multiple users display their apps on the screen at the same time is one,
thing. It's totally possible (as outlined three different ways and
clarified above) to do the same with audio, but it doesn't change the
principle of user *switching*. You've now made it clear that you are not
talking about user switching at all and thus a good chunk of this
discussion is moot.

What you are suggesting in the context of user swithing would be like
having multiple users with *separate* X11 desktops, but being able to
"zoom" out and see them both at once (like mutli-player games do on
consoles). That is not something that X can do (at least not easily that
I know of - it would require a system wide composition system) and it's
not something pulse does.


> Nothing to do with it being windows, it could be called Unix or Mac, it is 
> just a real limitation. Important or not?: that is a "value judgment", 
> which you have done some time ago, it seems, as I am one of "10 people who 
> 'moaned' about this", thanks again.

I really don't think that we are talking about the same thing now. I
hope my X11 examples have shown that.

I really don't think that in the context of user switching (which is
what you originally stated) that the need for multiple users all
outputting sound at the same time exists as a main-stream problem.

When both users will be sharing an X11 display anyway, the fact that
PA's configuration can piggy back on to X11 root window properties
solves a *lot* of the problems in achieving what you want. The only
problem you need to solve yourself is to ensure that filesystem
permissions allow user B to talk to User A, native PA socket and
everything will work fine (as stated above).

So I don't think you are even in the group of now 9 people who really
did moan about wanting concurrent sounds when user *switching* (and yes
the numbers are made up to emphasise my point!)


>> 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?
> 
> Where have I said anything about "crazy and outlandish"?

You didn't, I did :p Sarcasm may be the lowest form of wit, but it's all
I've got.

> Could you leave you pre-judgments out of this?

I will if you will :p You presume that your use case is the most
important thing in the world. That's a fair enough position to come from
as you're currently fighting with it and it's the highest priority thing
on your agenda right now. I've got the benefit of having heard this
argument before. If you had brought a new use case up, then I would have
tried to understand it and then address it rationally, but, sadly you've
not brought a new use case, so I will fall back on all the reasons for
why it's not done this way. Sorry, but that's the way it goes.

> A "tiny fraction", huh? That is exactly the mentality which drove me away 
> from windows. Exactly the bully of not wanting to hear user problems or 
> just pushing it aside by "not being in the use case we cover", thanks.

This is open source. I am motivated to do the stuff I do because I think
it's right solution and it works for me. I've listened to the arguments
many times and you've not brought anything new to the table. Perhaps I
could have explained the arguments better and for that I would
apologise, but it's certainly not about not wanting to hear the user
problems.

And besides, what is wrong with the "not being the user case we cover"?
What's wrong with a tool for a purpose that fits that purpose? If all
cars had to have wings so they could fly too, then a lot of pedestrians
would have their legs broken as they walk down the pavement and get hit
by wayward wings...

If I wonder into an ice cream shop and ask to by petrol for my car, I
wouldn't seriously expect them to sell me it because that's not what
they do.

(two car analogies in as many paragraphs... I think I get a prize for that).

> It seems broken mentalities sprout everywhere.

Thanks very much. I hope one of the three solutions I've given you will
ultimately work for you, but if they don't then you can attribute it to
my broken mentality.


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