[pulseaudio-discuss] system-wide daemon

[Markus Rechberger]

On Wed, Feb 10, 2010 at 9:54 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
> 'Twas brillig, and David Henningsson at 10/02/10 06:14 did gyre and gimble:
>> Colin Guthrie wrote:
>>> 'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble:
>>>> I wrote down a few use cases here, I'm sure there are more:
>>>>
>>>> https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio
>>>
>>> For user Foo, the sound card sounds like it's dedicated for Foo. If this
>>> is the case the a udev rule should be written to ensure that only Foo
>>> has ACL rights on this file and any console-kit udev-acl callouts are
>>> ignored.
>>
>> That makes sense, thanks. I added that reply to the blueprint.
>>
>>> For user Bar, I feel this is invalid. Why should user Bar have the right
>>> to output a sound any more than he has the right to display a popup
>>> window on my desktop?
>>
>> 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).


Best Regards,
Markus

> No scanners were identified. If you were expecting something different,
> check that the scanner is plugged in, turned on and detected by the
> sane-find-scanner tool (if appropriate). Please read the documentation
> which came with this software (README, FAQ, manpages).
> [test at jimmy colin]$ exit
> [colin at jimmy ~]$ scanimage -L
> device `plustek:libusb:005:011' is a Canon CanoScan LiDE25 flatbed scanner
>
> So yes, scanning is the same as sound right now. That's how ConsoleKit
> works. Printing is handled by cups and user access rights are handled
> therein.
>
> So there is nothing specifically wrong with the approach taken by cups,
> but by the same token, if every single subsystem implemented it's own
> system wide daemon and user authentication system we'd have a hell of a
> mess. As printing is quite often a network resource, then some kind of
> public facing daemon makes sense here.
>
> Standardising on the use of ConsoleKit makes a lot of sense.
>
>>> As for multi-seat, this is already in hand. Console-Kit has support for
>>> multi-seat stuff (tho' it may not be complete - I'm not overly sure
>>> here). What may still remain to be done is to tag certain devices as
>>> being for particular seats so that console-kit/udev can apply the
>>> appropriate ACLs when the set becomes active for a given user. All the
>>> multi-seat stuff is below PA tho' We'll just honour what it tells us. I
>>> don't think we don't need to add specific support for it.
>>
>> And the way ck/udev tells PA what devices it can use, is through device
>> permissions?
>
> Yeah, if we have permission on the device, we use it, otherwise it's
> ignored. When users are switched away, CK fires off dbus signals and we
> recheck our device access etc. We don't accept any input from alsa when
> we do not have permission on the device (even tho' we can read mixer
> settings). If we were able to access the device when we were started but
> subsequently have our permission removed, this is indicative of "user
> switching" (i.e. "Show Login Window" or "Switch User" or "Log in as a
> Different User") in which case we cork any streams tied to those devices
> we can no longer access until such times as they become available to us
> again.
>
> 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
>