'Twas brillig, and Ben Bucksch at 07/11/11 19:43 did gyre and gimble: > On 07.11.2011 19:59, Maarten Bosmans wrote: >> I would load module-protocol-native-tcp with ip-acl=127.0.0.1. >> Then for other users set PULSE_SERVER=localhost. > > Yes, that's what I recommended a friend, too. > Problem is: which pulse server is the main one and which one connects? > Any user can log in first. > > Also, what do you do in cases of e.g. mpd running as daemon (by design) > and needing to output sound, and GNOME running on the same machine. Note > that a lot of pulseaudio depends on an active X11 session, including the > dbus stuff, and bails if there isn't. > > Also note that many of the official disclaimers / stated problems of the > system-wide solution apply when you enable a network port and do stuff > as you suggest. > > May I recommend to officially support the system-wide solution and make > it work well? I don't see another solution for multi-user systems and > daemons. The term "multi-user systems" here is misleading. PA goes out of it's way to be multi-user friendly. What it does not do particularly well OOTB is multiple users at the same time, which, as stated, is by design. I do not want user A to login and play their Brittany Spears discog and lock their station meaning that I have to turn off all sound. I do not want user A to lock their station while running a program that would let them eavesdrop on my private VoIP calls. Now keep in mind that this method of working is NOT really a PA design anyway - yes the PA design fits in with this, but its the underlying layers of the system that set the permissions in the first place. Whether it's console-kit (rapidly becoming obsolete, but in use currently) or systemd-logind, both ultimately work with udev to ensure the ACLs for only the appropriate (i.e. active) user are written to the audio device nodes. The fact that Linux does not have a revoke() system to pull device access away from people meant that if a user had the audio device open when his privileges were revoked, he could still output sound. That's a bad situation but PA fixes that by noticing the permission changes and being a good citizen. But once closed, the user who has no writes on the device should not be able to play. Plain and simple, that's what the lower level permission system imposes. Now another thing that also works very well in the multi-user domain is mutli-seat systems. If you have systems where two people can login at the same time with separate keyboards, pointers and screens, then systemd is very capable of defining seats and allocating e.g. PCI devices or USB ports to each seat. PA will honour this and give each user access to his own USB or PCI sound card. While the practicalities are different, you cannot share single screen for graphics in this case, and sound is pretty much in the same boat. >> This recording thing is, among other things, one of the reasons >> multiple users aren't allowed to connect to eachothers pulse daemon by >> default. > > Exactly. But Martin and me now stated a few usecases where this is > *needed*. Saying "it's not recommended" and "yes, we know it's insecure" > doesn't solve the actual problem. If that's the result of the design, > then the design is obviously wrong and needs to be revised. Needed use cases are still possible. You have to do more work yourself. Depending on how distros package things, you may or may not have to do much more then tick a box in a GUI, but that is very much beyond our control. You have to run a system-wide daemon. It's not something we actively support because this use case is very much in the minority and it causes a lot of headaches and unnecessary overhead - one of the primary disadvantages is the inability to support ho tplugging properly (because any kind of system-wide process will totally ignore the users carefully configured seat configurations etc), causes obvious security problems relating to eavesdropping and also cannot use SHM memory and thus causes a lot more overhead when dealing with client-server communications - i.e. you need to copy the audio data over the wire. So while conceptually it's easy to say "you should support it, it's easy" you end up having to build a whole security manager into PA itself rather than rely on underlying systems. If we were to ever do that we'd get an equally vocal group of people saying "why the hell are you building security policy into PA, that's totally not it's job you idiots". So I say this: If you want system-wide PA, use system-wide PA. We do not recommend it, but it doesn't mean we'll sneak into your house at night and kill your kittens. You have extra overhead which may affect latency in games or voip and you have to make sure your users are in the pulse-access group. You might have to tweak certain files to get bluetooth working, you may not be able to use certain funky features such as network support etc. (tho' it should still be possible to teach SSH how to deal with PA natively - either per-user or system-wide, just like it does with X11 but sadly I just don't see it happening anytime soon). These are the trade offs and I don't think it's too much to ask. Oh and for the MPD case I believe that issue is very similar to the accessibility problem. There are daemons which run accessibility systems to provide contextual information to higher levels - such as scraping the console or reading the screen. These run in the background on the system, in the same way mpd runs. Now the actual output stage for the audio from either of these systems falls into two very broad categories: "system is idle waiting for login", "user is logged in". Now consider two users on an accessible system: One is visually impaired the other is not (and this is a multi-user system where the users do not log in at the same time). Obviously the visually impaired user will need the system to work at the "idle/login screen" stage and I'm sure the non-impaired user will accept this as a valid compromise (if not he's a total dick!). But when the non-impaired user logs in, he doesn't want the thing to tell him via the sound system what is on screen - he can see that himself. So my argument here is that it's NOT up to the underlying system (the accessibility scraper or mpd) to decide when it should output the sound, it's up to the user to decide. In the case of the login screen, this is the system-administrators job to decide. Some GUI somewhere should ask: Should the gdm user (or "login" user to be a little more generic) run the process that connects to mpd and plays the sound back Y/N? After that each user decides on their own whether or not to run that process too. This is an architectural change, but it allows the accessibility and mpd type use cases and utilises the underlying security modules of the system without baking anything specific into PA which, IMO is the correct approach. Now for the case of event sounds from non-active users I have a different solution. If you are not the active user but are logged in on the system, when you play an event sound (as signified in PA's media.role property on streams, there could exist a PA module that notifies the system dbus that such a notification wishes to be played. The active user also have the same dbus module loaded which as well as notifying out, also listens for other user notifications. In this case a generic "other user event" sound could be played. It wouldn't be the correct event sound but IMO this is actually desirable. You want to know that the aural feedback you've just received is for someone else. And that user should of course be able to disable such events. This is a relatively easy system to cook up IMO - should only take a day or so of hacking, although getting the design perfectly correct may be interesting (as we'd really want to trigger a libcanbera event for the "other user sound" event so really you'd want a dbus service on the system bus and a little demon to run, per-user as the process that listens for other user events - so not totally trivial) Anyway, herein lies the end of my suggestions to solve the problems experiences, not by letting all users have a free for all, but with controlled means of access. Hope you agree Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
