#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