Kay Sievers wrote:
On Thu, May 21, 2009 at 20:08, Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> wrote:
With some effort, we could add some fw_device attributes which reflect
fw_unit properties. We would have to encode a little bit of higher-level
knowledge into the fw_device handling part; but why not if it makes life for
userland considerably simpler.
Sounds ok to me, if we will end up with that solution.
Or maybe delay all uevents until the childs are all created, and send
the events only after that, so the child devices can be seen at the
time the event is sent out.
...
[thanks for the tips how to go about that]
...
And then, how would an udev rule look like to match attributes in the
fw_device's subdirectories instead of direct attributes?
SUBSYSTEM=="firewire", \
ATTR{*/specifier_id}=="0x00a02d", \
ATTR{*/version}=="0x00010?", \
GROUP="video"
This is always numeric, and the unit directory names are not
predictable, right? Then we would need something like the "*/..."
magic to udev.
Yes; the "dev" (character device file) sits in devices like
/sys/devices/pci0000:00/0000:00:05.0/0000:04:00.0/fw3
while the protocol-specific attributes sit in children like
/sys/devices/pci0000:00/0000:00:05.0/0000:04:00.0/fw3/fw3.0
i.e. "%s.%d", parent_name, number; with the number monotonously
increasing from 0 to n-1. There may be none to many of such children.
If there is no child at all, no problem, then the device won't be
interesting to typical application software anyway.
In many cases, there will be just one child, named like the parent with
.0 appended.
However, we also need to cover the case that there is more than one
child. Then the attributes of all children need to be evaluated.
BTW, the possible (but luckily highly improbable) case of devices with
several units of different type poses the question which policy to
follow: Paranoid = deny access unless all units are of a known good
type? Or comfortable = grant access if at least one unit is of known
good type? (My PROGRAM based patch actually implements the comfortable
policy, in case that wasn't obvious.) The paranoid case may have the
serious drawback that unknown types would prevent access to known types
even if the unknown ones are actually harmless to expose.
If we keep it that way that udev has to look at children attributes (if
this is feasible at all), then the policy for this mixed type case would
remain entirely in userspace. But if we go the route of the 1st
variant, i.e. copy children properties into parent's attributes, then we
need to be either very careful to solve it without hard-wiring policy
into the kernel, or end up with a bias of the kernel part towards one or
the other policy.
In practice, mixed unit types is a vitually non-existing case though.
We fixed almost all these know issues in other subsystems now and I
would really like to see that solved properly, without chrgrp hacks
like in the rules above. It would hit us back badly, when generic
infrastructure which will expect proper event timing regarding device
properties.
Hmm, or maybe we should associate character device files with the fw_units
instead? Could break Fedora's userland though. Alas I don't know in detail
what Fedora does to set ACLs on /dev/fw*.
Maybe it would be nice anyway, if some units-types can be excluded
from access by normal users. Sometimes it would be nice to have
something like this for USB, so we could grant access to the 3G modem
of mobile phone, but not to the firmware update interface :)
This is not possible with FireWire because the actual I/O, if not even
broadcast to the entire bus, can only be addressed to the FireWire node
in its entirety, not to particular units on the node. The node itself
(IOW the protocols which the node implements) needs to bring the
necessary separation between/ security of the units which reside
together on a node.¹
However, on second thought, providing character device files per fw_unit
won't work with current libraw1394 and libdc1394. They expect /dev/fw*
to represent one FireWire node (i.e. fw_device) each.
------------
¹) FireWire is not just a bus after all, it's also a network. Hence
device security is more like host-side security in the sense that the
device is a host. So, another not too far-fetched way to deal with
firewire-cdev permissions is this one:
SUBSYSTEM=="firewire", GROUP="video"
Still, doing it finer grained than this would be good. For example,
access to SBP-2 targets should remain a privilege, even though it would
require a non-trivial effort to do anything "interesting" to an SBP-2
target from userspace.
--
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/
--
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
