#11877 NORM 13.1.0: device permissions for USB devices should be more permissive
Zarro Boogs per Child
bugtracker at laptop.org
Mon Sep 3 16:51:02 EDT 2012
#11877: device permissions for USB devices should be more permissive
-----------------------------------+----------------------------------------
Reporter: pgf | Owner: dsd
Type: enhancement | Status: assigned
Priority: normal | Milestone: 13.1.0
Component: distro | Version: not specified
Resolution: | Keywords:
Next_action: never set | Verified: 0
Deployment_affected: | Blockedby:
Blocking: 10784 |
-----------------------------------+----------------------------------------
Comment(by dsd):
I guess our first run of this tries to take the "we should only look for
devices without a kernel driver" approach, at least judging by the
DRIVER="" part of the proposed rule.
{{{
SUBSYSTEMS=="usb", SUBSYSTEM!="block", DRIVER=="", MODE="0666"
}}}
It's a bit more complicated than this. All USB devices have one or more
device node - *always* one in /dev/bus/usb (usbfs, for use by libusb and
similar) and possibly another somewhere else (e.g. /dev/sda for a disk).
In the case when no kernel driver claims the device, the usbfs node is
still present. In the case when a kernel driver creates another device in
addition, that device is a child (or grandchild) of the usbfs node.
The problem is that udev rules can look at the parents of the device they
are configuring, but not children. So the above rule, which has the design
of trying to only operate on the usbfs devices (i.e. devices with no
kernel driver), actually configures /dev/bus/usb nodes to be read-write
even for devices that have kernel drivers, including block devices. This
means that a simple userspace app run as the olpc user could dump or erase
the contents of an external disk (which might otherwise be protected by
unix permissions) via the /dev/bus/usb node.
I can't see a simple solution here. We can't match against class codes,
because device classes are commonly specified by the interface (which
again is a child device of the one we're matching). We can't run a script
to look for child devices because the usbfs node gets created before any
possible driver pair has even been modprobed.
I see 3 options:
1. Accept that we don't care about the ability to read/write to all
devices, including block devices, and go with a rule similar to the above
(can be simplified just to match ENV{devtype}) that unconditionally sets
read-write on all usbfs nodes.
2. Write a script to be run by the udev rule to look for the interface
types of the device's child interfaces and make the decision based on that
3. Stick with what we have
For the case of sensors that are covered by a kernel driver (e.g.
legousbtower, hiddev for some lego devices), we will need individual rules
but we can make them "open" (e.g. set read-write on all hiddev devices),
and I expect them to be the minority.
--
Ticket URL: <http://dev.laptop.org/ticket/11877#comment:12>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system
More information about the Bugs
mailing list