Remove the "usb" group

[Randy McMurchy]

Version increment to 1.0.18

​http://www.sane-project.org/

[alexander@…]

SANE now comes with pre-made udev rules (sane-backends-1.0.18/tools/udev/libsane.rules) that assign mode 0660 and the "scanner" group to /dev/bus/usb/x/y devices that are scanners. This file is, however, not usable as-is, because long comments overflow a buffer in udev. After stripping out comments, the file becomes usable.

However, there is already a rule in BLFS that assigns all raw USB devices (not only scanners) to the "usb" group, so members of the "usb" group can use USB scanners even without this new file with rules. The new setup with the "scanner" group is more secure, though.

[dnicholson@…]

Agreed. We should create a scanner group. Maybe group 61 or 62?

[buo]

Attached a patch to upgrade sane to 1.0.18. Please review the change in disk space required, since it went down from 60MB to 3MB. I doublechecked and 3MB seems correct to me. I also tried to improve the wording a bit in one place.

Regarding the udev rules: as far as I understand it, it's important to use the included rules because it allows sane to load the appropriate firmware the first time the scanner is accessed. Without the included list of scanners, there's no way for it to know exactly which scanner it is talking too. So, it's not just a matter of permissions.

I added a scanner group locally (number 16), and {x,}sane just work.

[Randy McMurchy]

Updated BLFS to SANE Backends-1.0.18

I suppose we need to keep this ticket open as there seems to be some UDEV issues that need addressing. It would be nice if someone in the know would close this ticket and open a new one if the issue is still relevant.

[alexander@…]

IMHO, removing the "usb" group is a bit too big task for BLFS-6.3. So let's deal with it immediately after the release. I am also retitling the ticket to highlight the fact that it concerns not only SANE, but also GPhoto2 (not currently in the book), and that some text has to be written about VMware and QEMU USB permissions (these applications still use /proc/bus/usb).

[bdubbs@…]

This needs to be coordinated with #2692 and #2695, so I may as well do all of them.

[willimm]

New version 1.0.19.

[bdubbs@…]

Mostly fixed at revision 7691.

Updated to sane-backends-1.0.19. Added instructions to create a new scanner group ( gid 70 ). Copied sane udev file to 65-scanner.rules

I will not close this yet. Since I don't have a scanner, I need someone to test this for me.

Issues: I copied the scanner udev rules to 65-scanner.rules. Is 65 the right place? The comments above from two years ago say that long comments overflow a buffer in udev. I don't know yet if this is still true or not.

The title of the ticket says 'Remove the "usb" group' but that is a bit confusing. I don't see a reference to a usb group anywhere in BLFS. Since VMware, GPhoto2, and QEMU are not in the book, I don't see how that applies.

[alexander@…]

The "usb" group is only mentioned indirectly on the "About Devices" page, through "devgid=14", and this is relevant only for VMware and QEMU. There is no rule that puts all raw USB devices into this group. In fact, the title is a bit misleading. What I meant was to make VMware and QEMU the only programs where access to USB devices is controlled through the "usb" group. Previously, there were no rules for scanners, and by default (without reading the "About Devices" page) they worked for non-root only due to the old (now removed) LFS rule that put all raw USB devices into the "usb" group.

The comment about buffer overflow is obsolete. The only thing that remains to be done is to remove or replace the example with the scanner group on the "About Devices" page (btw, the mode is wrong there, as write access is required), as it is redundant. Or just mention that such rule already exists and is shown only for the purposes of demonstration.

So, I'll test this tomorrow and probably close the bug.

[alexander@…]

Found one more place where the "usb" group is mentioned: libusb page.

[alexander@…]

Tested SANE (frontends & backends, as well as xsane) in the following configuration:

Libtiff and libgphoto2 are installed. For libgphoto2, I used this:

groupadd -g 52 camera &&
./configure --prefix=/usr --sysconfdir=/etc udevscriptdir=/lib/udev &&
make &&
make install &&
/usr/lib/libgphoto2/print-camera-list udev-rules mode 0664 group camera >/etc/udev/rules.d/65-libgphoto2.rules

(please ignore the fact that a program is installed in /lib/udev that needs libraries in /usr - it will be retried when /usr is mounted)

For SANE backends and frontends, instructions were taken from the book. They don't quite work out of the box:

• There is a group ID conflict with sshd (reported as ticket #2796).
• The udev rules use the old SYSFS syntax. sed 's/SYSFS/ATTRS/g' does the conversion trick.
• Make sure that non-scanner USB devices (e.g., hubs) in /dev/bus/usb have 0664 permissions (i.e., are readable), because otherwise scanner access will fail. The working configuration is the default in LFS-6.4, but not in 6.3.
• I have to edit /etc/sane.d/gt68xx.conf so that my scanner is recognized as Mustek ScanExpress 1200 UB Plus and not the other model sharing the same USB ID, and save the firmware file from ​http://www.meier-geinitz.de/sane/gt68xx-backend/firmware/sbfw.usb as /usr/share/sane/gt68xx/sbfw.usb. Both actions are documented in the sane-gt68xx manual page. BLFS already directs the users there.
• The book says "Once the saned daemon has been configured, add any desired users to the scanner group". However, if the scanner is not supposed to be shared over the network, then the daemon is not supposed to be used (and thus is not supposed to be configured), and the users should still be added to the group. Even more, if both the daemon is used and the user is added to the group, then the local USB scanner will be seen twice: once directly and once as a network scanner connected to 127.0.0.1.

After correcting these issues, both xscanimage and xsane work as expected.

[bdubbs@…]

Replying to alexander@…:

• There is a group ID conflict with sshd (reported as ticket #2796).

Fixed at revision 7708.

• The udev rules use the old SYSFS syntax. sed 's/SYSFS/ATTRS/g' does the conversion trick.

Fixed at revision 7709.

• Make sure that non-scanner USB devices (e.g., hubs) in /dev/bus/usb have 0664 permissions (i.e., are readable), because otherwise scanner access will fail. The working configuration is the default in LFS-6.4, but not in 6.3.

This ticket is only addressing 6.4, but I added an erratum to BLFS 6.3 on the website.

• The book says "Once the saned daemon has been configured, add any desired users to the scanner group". However, if the scanner is not supposed to be shared over the network, then the daemon is not supposed to be used (and thus is not supposed to be configured), and the users should still be added to the group. Even more, if both the daemon is used and the user is added to the group, then the local USB scanner will be seen twice: once directly and once as a network scanner connected to 127.0.0.1.

Moved the instruction to add users to the scanner group and deleted the daemon reference.

Closing the ticket.

[alexander@…]

Reopening, as only the "SANE update" part has been addressed (and it no longer relies on the "usb" group). Milestone is set to future, because the "usb" group exists in LFS-6.4.

Let's remove it from LFS immediately after BLFS-6.4 release, and adjust BLFS SVN accordingly.

[bdubbs@…]

I have a couple of questions. Why do we need to remove the usb group completely? I would think it would be useful to have a default group for usb devices.

Second, with the exception of the 'About Devices' section where there is an example line:

usbfs /proc/bus/usb usbfs devgid=14,devmode=0660 0 0

where the 14 is the usb group defined in LFS, my search showed no references to the usb group in all of BLFS. I could have missed it though.

Exactly what do you think should be done to re-close this ticket?

[alexander@…]

Why do we need to remove the usb group completely? I would think it would be useful to have a default group for usb devices.

The "usb" group has been created by me as a very insecure solution to the problem "no way to access a scanner as a user" that appeared just before LFS-6.0 because the old /dev/scanner node was no longer supported by linux-2.6.x, and because the more fine-grained access control mechanism (hotplug scripts) was explicitly disallowed for LFS-6.0 by Matthew Burgess. The fine-grained permissions problem no longer exists, so nothing needs this group, possibly except emulators that need to access arbitrary USB devices in a generic way. IMHO, a group is useless if it is not used.

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);
• 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);
• 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.

Second, with the exception of the 'About Devices' section where there is an example line:

usbfs /proc/bus/usb usbfs devgid=14,devmode=0660 0 0

my search showed no references to the usb group in all of BLFS. I could have missed it though.

Yes, you have missed the libusb page: ​http://www.linuxfromscratch.org/blfs/view/svn/general/libusb.html

[bdubbs@…]

Replying to alexander@…:

The "usb" group has been created by me as a very insecure solution to the problem "no way to access a scanner as a user" ... The fine-grained permissions problem no longer exists, so nothing needs this group, possibly except emulators that need to access arbitrary USB devices in a generic way. IMHO, a group is useless if it is not used.

If that's the case, there are several groups in LFS that should be removed. Without doing an exhaustive check, I don't know of anything using the bin, sys, or daemon groups although they are "traditional".

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.

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.

• 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? Is the comment in "About Devices", "USB Device Issues" still valid or should that be dropped too?

• 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.

[alexander@…]

Replying to bdubbs@…:

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.

[bdubbs@…]

Fixes at revision 8297.

[bdubbs@…]

Milestone renamed