Bruce Dubbs wrote:
From this discussion, is seems there needs to be a separate group for
each device and users be given appropriate permissions for those
devices. This seems to be a general security administration issue, not
a LFS or BLFS issue. It may be appropriate for HLFS.
While I disagree (and I was actually going to implement this for scanners and
cameras), let's implement this your way. Let the "usb" group stay. The current
BLFS rule SUBSYSTEM=="usb_device", GROUP="usb" does just that. However, I want
to see text that is going to be added to HLFS in order to override this (and I
am not subscribed to HLFS lists).
Perhaps this should be covered in a section called "Removable Devices
and Security." Do I have any volunteers to write it?
Maybe. Let's first address the "how are readers going to find the note about
VMware and /proc/bus/usb" issue first. Summary: the text is good, the place is
wrong.
Proposal: create a new page (in post-lfs configuration?) with the title: "Access
to USB devices" and move libusb configuration to there (of course, with a link
from libusb to this new page). Proposed contents:
There are two ways to access USB devices in Linux.
1) Through a specialized kernel driver, e.g., usb_storage. In this case, such
driver creates nodes in /dev (in this case, /dev/sd*), and software opens or
mounts them. Permissions to open the device are set through those device nodes,
and can be changed via custom udev rules matching on kernel names and other
attributes. E.g., in LFS, the /dev/sd* nodes that represent USB storage belong
to the "disk" group by default, as other SCSI-like disks.
2) Through a userspace driver, such as SANE or gPhoto2 library. The kernel
provides two equivalent interfaces for such userspace drivers: usbfs (obsolete)
and nodes in /dev/bus/usb. Most of userspace drivers use libusb and, therefore,
manipulate the device nodes in /dev/bus/usb.
LFS already contains a rule to create devices with names like /dev/bus/usb/1/2
for each USB device. If an application can open such "raw" device, it can do
everything with it (including possible damage and bypassing permissions on
device nodes belonging to a kernel-space driver for the same device).
<remove if LFS implements an equivalent of this>
This rule will put all raw USB devices into the "usb" group:
SUBSYSTEM=="usb_device", GROUP="usb"
Write it into 30-usb.rules file. Add users to the "usb" group if they really
need raw access to all USB devices. Note that membership in this group is
equivalent to the "disk" group when access to USB storage devices is considered.
Generally, it is considered a better idea to use more fine-grained permissions
on /dev/bus/usb nodes.
<end of text to remove>
Fine-tunuing of permissions is possible by creating extra udev rules, matching
on something like this (on one line). The vendor and product can be found by
searchng the /sys/devices directory entries after the device has been attached.
SUBSYSTEM=="usb_device", SYSFS{idVendor}=="05d8", SYSFS{idProduct}=="4002",
GROUP:="scanner"
<begin of text to be added when I adjust SANE and gphoto2 instructions>
Usually, you don't have to create such rules yourself, they are installed with
SANE and libgphoto2 packages for all known scanners and cameras.
<end of text to add>
Some old programs that manipulate USB devices directly (instead of using libusb)
have not been adapted to the new /dev/bus/usb interface. VMware is an example of
such program. For these programs to work, the following line in /etc/fstab is
needed:
usbfs /proc/bus/usb usbfs devgid=14,devmode=0660 0 0
This line assigns the "usb" group to all pseudofiles in /proc/bus/usb. It is
possible to control the permissions of all pseudofiles at once by changing the
devgid and devmode options. There is no race-free way to set fine-grained
permissions. Therefore, use this fstab entry only if you know that you need it.
If a program does not use the /proc/bus/usb/devices pseudofile, it is possible
to convert it to the new interface by merely changing "/proc/bus/usb" to
"/dev/bus/usb" in the source.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
