On Wed, Dec 23, 2009 at 12:57 PM, Lennart Poettering <lennart at poettering.net> wrote: > On Tue, 22.12.09 17:54, Markus Rechberger (mrechberger at gmail.com) wrote: > >> >> Well, but nevertheless an X session is required to allow differend user >> >> accounts to access the audio subsystem at the same time. This is a >> >> drawback for me as I'm used to do a lot of my daily work on a text >> >> console outside of a X session, so I need to run X just to share audio >> >> access between different user accounts. >> > >> > This is a bit confused. >> > >> > PA does indeed *not* allow multiple users simultaneous access to the >> > same audio device. This is because we consider the sound card to be >> > part of the user seat, >> >> And this is the problem because it works with alsa, simply add every >> user you want to give audio access to the audio group and it worked. >> Even with OSS this worked. But PA breaks this behaviour. > > First of all, we broke exactly nothing. You can always bypass PA and do > stuff like this. > > Secondly, allowing access to the audio device to all users is a > security hole as I tried to explain quite a few times. Allowing that > means a user can evesdrop into your voip calls, he can even completely > monitor whatever you say when you sit in front of your computer. You > don't allow access to your kbd and screen to all users either, > right? it was a security issue that has been open for a long long time > that access to audio devices was not regulated the same way as acess > to your kbd and screen. We fixed that. Just because something works > differently than it worked before it doesn't mean it's broken. > >> How about I set up an FM Radio server, there's a daemon process >> accessible through a website which runs either as root or as his own >> dedicated audio user - there we already have our use case. > > If you use a server-like setup, i.e. a headless machine without local > sessions, then use system mode of PA. (or bypass PA) > >> I can even imagine that with OSX it does not cause any issue to log in >> from a remote host and play some audio. > > Actually OSX does exactly the same thing when you switch between > sessions: it stops output from one session and enables output on the > other. Mentioning OSX as an example here is really something that > can only backfire... > > Also, as Colin pointed out SSH logins certainly want audio output on > the terminal side, not the server side. > >> Please just fix this. > > There is nothing to "fix". > >> > the same way as the keyboard, the mouse, or the >> > screen. If we'd allow multiple users access then they might eavesdrop >> > into your voip calls or even record anything you say from the mic. As >> > long as a user is active on a seat he should be the only one who has >> > access to its devices. >> > >> >> I don't think it's innovative to cut the possibilities back we had >> before, it should be up to the user what he wants to do and what not. > > Right. It is innovative to carry on with the brokeness we always had > just because we always had it and not because we would ever think > about the brokeness and fix it? Is that what you think? > Right, we had /etc/group for setting up the permissions pulseaudio breaks this behaviour even with the Alsa compat library. > Also, the same discussion we already had 2 years ago on fedora-devel > and other mailing lists. Kinda pointless bringing this up again and > again and again. > Sorry this behaviour is just broken, Pulseaudio should not be part of any distribution until a certain level of compatibility is reached. compiz is optional it's easily possible to enable or disable it. The recommendation to use system mode is also a failure, why should someone reconfigure the entire audio system on a distribution? We have deployed alot devices which depend on audio nowadays at certain b2b customers, guess how many are using pulseaudio? -- exactly noone. After talking to engineers everyone feels like PA is just a pain, and by forcing your ideas which break the default behaviour this situation will not improve. I'd rather like to see a clear statement why it is currently not working, so someone can get onto that topic and fix it. If you want to block it for other users add a configuration option for it but again don't break the default behaviour Markus
