#2065: Remove the "usb" group
----------------------------------------+-----------------------------------
Reporter: ra...@… | Owner: bdu...@…
Type: task | Status: reopened
Priority: normal | Milestone: future
Component: BOOK | Version: SVN
Severity: normal | Resolution:
Keywords: |
----------------------------------------+-----------------------------------
Comment(by alexan...@…):
Replying to [comment:19 bdu...@…]:
> If that's the case, there are several groups in LFS that should be
removed.
Yes, it sounds logical.
> I do note that the udev default rules and udev-config/55-lfs.rules use
the group uucp that is not created by LFS. I have created a ticket in LFS
to address this. I am also proposing that LFS drop the usb group
completely and let BLFS handle it completely if needed at all.
You are right.
> > In order to close this ticket:
> >
> > * the "usb" group should not be created by default, exactly as we
don't create the "scanner" group by default (here you may disagree);
>
> That is an LFS issue, not BLFS. It is a part if the LFS ticket I just
created.
Indeed. But some coordination is needed.
> > * all the information about this group (including the udev rule from
the libusb page) should be moved to one place (maybe, the "about devices"
page);
>
> So we should just drop the "Configuring Libusb" section of libusb?
I am on the fence here.
> Is the comment in "About Devices", "USB Device Issues" still valid or
should that be dropped too?
This is still valid. But the group assignment must be consistent with
/dev/bus/usb, not because it will break otherwise but just for the reasons
of consistency.
> > * the reader should be informed about the possible use cases for this
group (i.e., a list of applications that may need this group and can't use
fine-grained permissions) and the risks associated with membership in it.
>
> That's fine. Give me some wording to use. It is contradictory to do
that though if you still say we need to remove the usb group completely.
Yes, sorry for that contradiction. As I said, I am on the fence. Assuming
that the only valid use for the "usb" group is related to emulators that
are beyond BLFS, maybe we can have this:
* on the "About Devices" page, swap the "USB Device Issues" and "Udev
Device Attributes" sections;
* in the "Udev Device Attributes" section, bring the example up to date.
The obsolete part is the use of SYSFS instead of ATTR or ATTRS. You can
copy a real rule from SANE, minus the ENV part;
* in the "USB Device Issues" page, instead of the existing text, use the
text below;
* instead of the current configuration section of libusb, add a link to
the "About Devices / USB Device Issues" page.
--------------
USB devices usually have two kinds of device nodes associated with them.
The first kind is created by device-specific drivers (e.g.,
usb_storage/sd_mod or usblp) in the kernel. E.g., for a USB mass storage
device, that would be /dev/sdb, and for a USB printer, that would be
/dev/usb/lp0. These device nodes exist only when the device-specific
driver is loaded.
The second kind of device nodes (/dev/bus/usb/BBB/DDD, wgere BBB is the
bus number and DDD is the device number) is created even if the device
doesn't have a kernel driver. By using these "raw" USB device nodes, an
application can exchange arbitrary USB packets with the device, i.e.,
bypass the possibly-existing kernel driver.
Access to raw USB device nodes is needed when a userspace program is
acting as a device driver. However, for the program to open the device
successfully, the permissions have to be set correctly. By default, due to
security concerns, all raw USB devices are owned by user root and group
root, and have 0644 permissions (the read access is needed, e.g., for
lsusb to work and for programs to access USB hubs). Packages (such as SANE
and libgphoto2) containing userspace USB device drivers also ship udev
rules that change the permissions of the controlled raw USB devices. E.g.,
rules installed by SANE change permissions for known scanners, but not,
e.g., printers. The "Udev Device Attributes" section below contains an
example of such rule. If a package maintainer forgot to write a rule for
your device, report a bug to both BLFS (if the package is there) and
upstream, and write your own rule, as explained in that section.
There is one situation when such fine-grained access control with pre-
generated udev rules doesn't work. Namely, PC emulators such as KVM, QEMU
and VirtualBox use raw USB device nodes to present arbitrary USB devices
to the guest operating system (note: patches are needed in order to get
this to work without the obsolete /proc/bus/usb mount point described
below). Obviously, maintainers of these packages cannot know which USB
devices are going to be connected to the guest operating system. You can
either write separate udev rules for all needed USB devices yourself, or
create a catch-all "usb" group, members of which can send arbitrary
commands to all USB devices:
{{{
groupadd -g 14 usb
cat > /etc/udev/rules.d/53-usb.rules << "EOF"
# Set group ownership for raw USB devices
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GROUP="usb", MODE="0664"
EOF
}}}
(not for the book: MODE is needed because the default from
/lib/udev/rules.d/50-udev-default.rules is 0644, and the rule number is
changed for the same reason)
Before linux-2.6.15, raw USB device access was performed not with
/dev/bus/usb/BBB/DDD device nodes, but with /proc/bus/usb/BBB/DDD
pseudofiles. Some applications (e.g., VMware Workstation) still use only
this deprecated technique and can't use the new device nodes. For them to
work, create the "usb" group, members of which will have unrestricted
access to all USB devices, and create the fstab entry for the obsolete
usbfs filesystem:
{{{
groupadd -g 14 usb
cat >>/etc/fstab <<"EOF"
usbfs /proc/bus/usb usbfs devgid=14,devmode=0664 0 0
EOF
}}}
Note: adding users to the "usb" group is inherently insecure, as they can
bypass access restrictions imposed through the driver-specific USB device
nodes. E.g., they can read sensitive data from USB hard drives without
being in the "disk" group. Avoid creating this group, if you can.
--
Ticket URL: <http://wiki.linuxfromscratch.org/blfs/ticket/2065#comment:20>
BLFS Trac <http://wiki.linuxfromscratch.org/blfs>
Beyond Linux From Scratch
--
http://linuxfromscratch.org/mailman/listinfo/blfs-book
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
