udev: Access permission of fw character device in which fw node includes unit handled by ALSA

udev: Access permission of fw character device in which fw node includes unit handled by ALSA

[Takashi Sakamoto]

Hi all,

I'm an ALSA developer, mainly committing to drivers for audio and
music units on IEEE 1394 bus (yes, it's legacy FireWire). I have a
concern about access permission for fw character device.

In the last few years 9 drivers have been added to support 120 models
around[1]. The drivers allow ALSA applications to transfer audio data
frames and MIDI messages, but they expect userspace application to
use fw character device for operations of the other functionalities
such as physical volume controls.

At present, for some models, udevd configures fw character device for
good access permission to userspace applications. On the other hand,
for the other models, udevd doesn't. In my opinion, for one half of
supported models, fw character device is configured with root:root/0500.

I'd like to change this inconvenience, changing group ownership of the
special file to 'audio', and add ACL +uaccess when logging in.

For your information, I prepare a repository including image of
configuration ROM from supported devices[2]. At present, 80 images are
added.  You can parse the image by crpp in linux-firewire-utils
repository[3].

At present I assume three options:

1. Add entries into udev rules for each of device

This is an enhancement of existent rules[4][5] and simple solution.
But developers always take care of adding new entries when users suggests,
perhaps.

2. Reconfigure fw character device when ALSA firewire driver is attached
   to unit

IEEE 1394 specification refers to IEEE 1212 to represent device and its
functionalities. Each device is represented as 'node' and its
functionalities are represented as 'unit'. The information about 'node'
and 'unit' is in configuration ROM.

Linux firewire subsystem reads content of the ROM, parses
it and adds fw character device to system for 'node', then binds in-kernel
driver to 'unit'. Kevents for the node and unit are generated separately.

If udevd handles unit kevent to seek binding driver then configures fw
character device, developers don't need to maintain rule list. Although
one node is allowed to have several units, nut the most of supported
models have only one unit, except for Applie iSight[6].

3. Fulfill hwdb to have supplemental information

I'm not good at hwdb, but according to its name, hwdb is good to store
device dependent information. If adding some hints to database and
using the information, this issue might be solved.

I'm happy to receive your comments to improve this situation.

As a mockup of such control application, I wrote libhinawa[7] and
hinawa-utils[8]. They're my (rough) private work and out of ALSA project,
but for future I wish to propose better implementation to ALSA project
as a control server program.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/firewire/Kconfig
[2] https://github.com/takaswie/am-config-roms/
[3] https://github.com/cladisch/linux-firewire-utils
[4] https://github.com/systemd/systemd/blob/master/rules/50-udev-default.rules.in
[5] https://github.com/systemd/systemd/blob/master/src/login/70-uaccess.rules.m4
    This rule refers to a rule optionally added by FFADO project.
[6] This device has four units; IIDC, Audio, vendor-dependent and IRIS.
[7] https://github.com/takaswie/libhinawa/
[8] https://github.com/takaswie/hinawa-utils/


Regards

Takashi Sakamoto
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: udev: Access permission of fw character device in which fw node includes unit handled by ALSA

[Lennart Poettering]

On Mo, 20.05.19 21:27, Takashi Sakamoto (o-takashi@sakamocchi.jp) wrote:

> Hi all,
>
> I'm an ALSA developer, mainly committing to drivers for audio and
> music units on IEEE 1394 bus (yes, it's legacy FireWire). I have a
> concern about access permission for fw character device.

I am not sure I understand firewire well enough to say something too
smart. But if I understand correctly, then we (in systemd upstream)
currently only have these four firewire specific rules in our tree:

  SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x00010*", GROUP="video"
  SUBSYSTEM=="firewire", ATTR{units}=="*0x00b09d:0x00010*", GROUP="video"
  SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x010001*", GROUP="video"
  SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x014001*", GROUP="video"

And all of these are handled by some firewire core driver? The devices
you care about, how would the rules look like for this?

In general, when it comes to auto-loading of drivers we usually expect
the kernel to add modalias metadata to .ko files.

In the hwdb usually mostly only "auxiliary" data is stored, i.e. stuff
that is great to have but is not essential for a device to work
basically.

Rules files should generally be kept short. i.e. if you add 3 more
rules for the devices you care about, that'd be fine — if you add 100,
then that's not so great however, and another approach should be
found.

Anyway, given that I am not a firewire pro, I figure you have to
decide yourself what the best approach is, and then prep a PR and we
can have a look. Without looking at an (maybe just RFC) patch I am not
sure I grok enugh to properly comment on it.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [FFADO-devel] udev: Access permission of fw character device in which fw node includes unit handled by ALSA

[Jonathan Woithe]

On Mon, May 20, 2019 at 09:27:27PM +0900, Takashi Sakamoto wrote:
> I'm an ALSA developer, mainly committing to drivers for audio and
> music units on IEEE 1394 bus (yes, it's legacy FireWire). I have a
> concern about access permission for fw character device.
> :

This was CCed to the FFADO-devel list.  My linux boxes don't use systemd and
I have only a superficial picture of systemd, so I don't think I can offer
any suggestions.  Furthermore, FFADO ships a collection of udev rules which
seem to do the job for FFADO regardless of whether systemd is used or not. 
Consequently it appears that the above discussion is not directly relevant
to FFADO.

If there are connections I'm not aware of please fill me in and I'll respond
accordingly.

Regards
  jonathan

Re: udev: Access permission of fw character device in which fw node includes unit handled by ALSA

[Takashi Sakamoto]

Hi Lennart,

Thanks for your reply, and notice to this legacy and minor issue ;)

On Mon, Jun 17, 2019, at 22:26, Lennart Poettering wrote:
> On Mo, 20.05.19 21:27, Takashi Sakamoto (o-takashi@sakamocchi.jp) wrote:
> 
> > Hi all,
> >
> > I'm an ALSA developer, mainly committing to drivers for audio and
> > music units on IEEE 1394 bus (yes, it's legacy FireWire). I have a
> > concern about access permission for fw character device.
> 
> I am not sure I understand firewire well enough to say something too
> smart. But if I understand correctly, then we (in systemd upstream)
> currently only have these four firewire specific rules in our tree:
> 
>   SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x00010*", GROUP="video"
>   SUBSYSTEM=="firewire", ATTR{units}=="*0x00b09d:0x00010*", GROUP="video"
>   SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x010001*", GROUP="video"
>   SUBSYSTEM=="firewire", ATTR{units}=="*0x00a02d:0x014001*", GROUP="video"
> 
> And all of these are handled by some firewire core driver?

Although it's probable that some of them are handled by in-kernel
driver (perhaps firedtv.ko), they're just for userspace applications.
The in-kernel driver adds another device to system (in this case
video character device) and access rules to it are apart from the one
for fw character device, as long as all features are implemented in
the in-kernel driver.

In a case of drivers in ALSA firewire stack, we decided to implement
a part of features in userspace application, due to the complexity of
vendor-dependent protocols. The in-kernel drivers just implement
isochronous packet streaming for PCM frames and MIDI messages, and
tells userspace applications the related fw character device via
ALSA hwdep interface[1].

> The devices you care about, how would the rules look like for this?

Here, I'd like to explain about the relationships between instances on
IEEE 1394 bus topology and fw character device, modalias on in-kernel
driver.

```
IEEE 1394 bus
 + node A        (=fw character device, /dew/fw0)
    + unit A1    (=modalias on in-kernel driver, fw0.0)
    + unit B2    (=modalias on in-kernel driver, fw0.1)
    + ...
 + node B        (=fw character device, /dev/fw1)
    + unit B1    (=modalias on in-kernel driver, fw1.0)
    + unit B2    (=modalias on in-kernel driver, fw1.1)
    + ...
 + ...
```

The relationship between node/unit is similar to device/interface in
USB case. One node can includes several units which represent
actual functionalities, and any in-kernel driver is bound to one of the
units. On the other hand, fw character device is added for each node.
The node is subject of communication.

When any driver in ALSA firewire stack is bound to one of units in a node,
I expect udevd to change group of the corresponding fw character device to
'audio', and expect logind to assign ACL to it.

 + node A    (fw character device with 'audio' group, +uaccess)
   + unit A1 (any driver in ALSA firewire stack is bound to)

In current framework of udev rule, this seems to be difficult to achieve,
in my opinion. Thus, if I managed to achieve it by rule framework,
I would add and maintain many entries generated from my registry[2].

> In general, when it comes to auto-loading of drivers we usually expect
> the kernel to add modalias metadata to .ko files.
>
> In the hwdb usually mostly only "auxiliary" data is stored, i.e. stuff
> that is great to have but is not essential for a device to work
> basically.
>
> Rules files should generally be kept short. i.e. if you add 3 more
> rules for the devices you care about, that'd be fine — if you add 100,
> then that's not so great however, and another approach should be
> found.

Yes. I'd like to avoid increasing maintenance cost of anybody including
myself...

> Anyway, given that I am not a firewire pro, I figure you have to
> decide yourself what the best approach is, and then prep a PR and we
> can have a look. Without looking at an (maybe just RFC) patch I am not
> sure I grok enugh to properly comment on it.

Okay. I'll attempt to post several RFC patches. It takes me a bit long
time because this is my first attempt to commit systemd, but I'm happy
if you review and comment to them.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/sound/firewire.h#n93
[2] https://github.com/takaswie/am-config-roms


Thanks

Takashi Sakamoto
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel