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

[Mark Cross]

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?
 
> 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?
 
> 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
     $
     $ _


> 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?

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.

> 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.
 
> 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".

> 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.

>> 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"?

I feel exactly as the time when I was discussing disk usage with a Windows 
representative:
    -- No, sorry, the copy of the backup of unused data is the way the
       system was designed to work, accept it. Besides, disk space is very
       cheap this days, what is the problem with using 120 Gigabytes of
       additional disk space?
    -- Maybe because I paid for the disk and I believe I have the right
       to decide what should be stored in it?

And I decided, not using Windows now.



So you understand, I'll explain in length what is the reason.

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* .

>> 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!!.

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?
 
>> 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.

Yes, you have made that very clear: "just a 10 users need".

>>> 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"?

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.

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.
 
> 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"?
Could you leave you pre-judgments out of this?

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.

It seems broken mentalities sprout everywhere.

-- 
Mark Cross