Re: [PATCH] udev: Allow ALSA input jacks to be accessed by the

[Lennart Poettering <lennart@poettering.net>]

On Fri, 17.06.11 13:27, David Henningsson (david.henningsson@canonical.com) wrote:

> On 2011-06-16 17:02, Takashi Iwai wrote:
> >At Thu, 16 Jun 2011 16:55:39 +0200,
> >Kay Sievers wrote:
> >>
> >>On Thu, Jun 16, 2011 at 16:48, Takashi Iwai<tiwai@suse.de>  wrote:
> >>>At Thu, 16 Jun 2011 16:28:08 +0200,
> >>>Kay Sievers wrote:
> >>>>
> >>>>On Thu, Jun 16, 2011 at 16:12, David Henningsson
> >>>><david.henningsson@canonical.com>  wrote:
> >>>>>One missing piece for userspace (PulseAudio etc) to actually be able to use
> >>>>>the jack input devices that ALSA create, is that these devices are
> >>>>>accessible by root only. This patch makes the input device nodes accessible
> >>>>>by the same users that can access the sound card: the current logged in
> >>>>>user, as well as users in the audio group.
> >>>>>
> >>>>>One thing I was thinking about, was that the udev-acl rule actually grants
> >>>>>read-write access to the input device node, where probably only read access
> >>>>>is needed. Is this dangerous?
> >>>>
> >>>>Takashi, wasn't there already something else to use from ALSA than the
> >>>>artificial input devices?
> >>>
> >>>These input devices are just notification from the sound driver at
> >>>jack plugging, so basically it's read-only indeed, and setting the
> >>>file permission RO would make sense.
> 
> So the problem is that there is no way to accomplish that in
> 70-acl.rules right now. Would it be some kind of security flaw if we
> allowed write access? What can you really do/damage by writing to
> these things?
> 
> >>Na, I mean, I remember you talking about some other channel of
> >>notifications about jack changes.
> >
> >Ah, yeah, it's still possible to implement via ALSA control API, too.
> >Just add a new control element for jack notification, and the apps can
> >listen to it via normal ALSA API like the mixer elements.

Takashi, what's the perspective on this? Your patches, would they
convert *all* existing drivers to this new interfaces, or just HDA?

If we add new infrastructure to udev (and PA), does it really make sense
to that with an interface that is suboptimal and is going to be replaced
very quickly anyway?

If you have the patches ready to convert all drivers which currently can
do jack sensing over to the new scheme with control elements, then we
should probably focus on that for the future, shouldn't we?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.