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

[Takashi Iwai <tiwai@xxxxxxx>]

At Fri, 17 Jun 2011 14:31:48 +0200,
Lennart Poettering wrote:
> 
> On Fri, 17.06.11 13:27, David Henningsson (david.henningsson@xxxxxxxxxxxxx) 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@xxxxxxx>  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@xxxxxxxxxxxxx>  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?

So far, only HD-audio and ASoC drivers provide the jack-sensing
notification.  My patch didn't change ASoC drivers, so it's only about
HD-audio.

> 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?

We've had already this infrastructure for years, but mostly used by
ASoC, so basically independently from desktops, thus they had little
care about the file permissions.

> 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?

For PA work, I suppose so (although I won't object to someone working
on the implementation with the present input-jack layer :)
But you can see David's patch basically independent from PA.


thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html