[pulseaudio-discuss] system-wide daemon

[Bill Cox]

Here's what I don't understand.  Why doesn't PA run in system-wide
mode, but still do all the same user-permission checks it does now,
and only authorize the current user to access the sound card?  Is
there any advantage in running the whole PA daemon in user space?  Why
have multiple PA processes running when there are multiple users?
Doesn't this waste memory?

If PA were run this way, it would be trivial to allow specific root
processes or authorized users to access the sound card at the same
time as the current user.

Also, why does zero latency by default increase CPU power?  SFAIK,
zero latency (or inperceptably small) is the default in all other
sound systems, and I haven't heard of increased CPU usage as a result.

Thanks,
Bill

On Wed, Feb 10, 2010 at 4:13 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and Markus Rechberger at 10/02/10 08:59 did gyre and gimble:
>> On Wed, Feb 10, 2010 at 9:54 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>>>> Here's another analogy; what about the printer? If printers were
>>>> considered a part of the seat, then user Bar wouldn't have more right to
>>>> print a document either. (The corresponding spy-on-mic analogy would be
>>>> that someone puts a document in a scanner and another user scans it...)
>>>>
>>>> But printers are more of a system-wide resource, and for some use cases,
>>>> so is the soundcard. And then, sharing makes sense. If another user is
>>>> allowed to print a document while I'm logged in, why shouldn't he be
>>>> able to play a sound? So would then the solution be to run PA as a
>>>> system-wide daemon, and possibly assign soundcards to it via udev?
>>>
>>> It's a fair enough point, but I don't think that sound and printers are
>>> so alike. Even the scanner example AFAIK would fall under the current PA
>>> setup - I believe that sane accesses them on a per-user basis with
>>> appropriate ACLs on the device..
>>>
>>> /me checks....
>>>
>>> [colin at jimmy ~]$ su test
>>> Password:
>>> [test at jimmy colin]$ scanimage -L
>>> libusb couldn't open USB device /dev/bus/usb/005/011: Permission denied.
>>> libusb requires write access to USB device nodes.
>>>
>>
>> this is another wrong assumption, libusb uses raw USB access, if every
>> user would have access
>> to USB some devices might be damaged.
>> Sane would need to be serverbased, full raw access to the usb bus
>> would seriously be a security
>> risk (imagine RAW USB access to a USB harddisk).
>
> I fail to see where my assumption is here.
>
> Console-Kit has applied appropriate ACLs to the device node. That was my
> point and it was correct. No assumption stated nor needed as to what
> happens further down the stack.
>
> [test at jimmy colin]$ getfacl /dev/bus/usb/005/011
> getfacl: Removing leading '/' from absolute path names
> # file: dev/bus/usb/005/011
> # owner: root
> # group: root
> user::rw-
> user:colin:rw-
> group::rw-
> mask::rw-
> other::r--
>
>
> The same is true of audio devices. What if multiple users were allowed
> direct access. Someone may design a security system with an alarm driven
> from the sound system but some other user has come in and hogged the
> device and as it does not support hardware mixing the "nuclear reactor
> meltdown in 5mins" alarm does not sound and we all die a horrible firey
> death. That's worse than a HD failure :p
>
>
> 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/]
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>