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

[Takashi Sakamoto <o-takashi@sakamocchi.jp>]

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