On Wed, 2007-12-19 at 11:31 +0100, Lennart Poettering wrote:
On Wed, 19.12.07 12:12, Neil Thompson (abraxis(a)telkomsa.net) wrote:
> > Also, I'd argue even if it worked before (which it didn't) the
> > behaviour exposed by PA+CK is the more correct one, from a security
> > perspective. And hence speaking of a "regression" in this area is
> > adventurous.
> Something that used to work without issues, doesn't any more...looks like
> a duck, walks like a duck...
Sorry, but it *didn't* work before.
By default the access mode of the dmix SHM is 0600. i.e. only a single
user ID may access the sound card at a time.
I am ok with the answers you gave, but here I can't agree with you.
user A play music, F-U-S, music keep playing.
user A play music, F-U-S, music stop playing.
I understand it make sense that the new scenario is the default for
security reasons, I agree, but don't say there is no difference.
If you want to open up dmix to multiple users at the same time you
need to change it to 0666 or so, which is a security hole and needs
some non-trivial reconfiguration.
Only if you have a mic, common on laptops, uncommon on desktops (just my
The reconfiguration necessary to open up PA to other users is a lot
simpler to do. Just copy a cookie file around.
This require knowledge that is beyond normal users, if this is something
users are expected to do, then a simple configuration dialog should be
> And then the use case just gets dismissed.
Paraphrasing..."the clueless newbie
> who doesn't really use her machine will be OK, and the other folks will just
> to change the way they work".
I didn't dismiss your use case at all. All I told you is that the kind
of setup you envision required non-trivial reconfiguration before, and
it requires reconfiguration now. So, calling this is a regression is
And yet it would be nice to make it possible to have the 2 major use
cases working easily:
A) Only the active session have access to sound
B) Everybody have access to sound
A big switch in the sound configuration window is all is needed
(including scary warnings about the insecurity of option B).
| Simo S Sorce |
| Sr.Soft.Eng. |
| Red Hat, Inc |
| New York, NY |