Project

General

Profile

Bug #5542

devfsadm fails to set usb child device permissions per /etc/minor_perm

Added by Warren V almost 5 years ago. Updated almost 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2015-01-16
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

Upon installing a USB HID device (using ugen), the following /devices entries are seen:

root@sanbox:/devices/pci@0,0/pci15d9,803@1d/hub@1# ls al
total 17
drwxr-xr-x 5 root sys 27 Dec 18 16:07 .
drwxr-xr-x 3 root sys 3 Dec 16 20:14 ..
drwxr-xr-x 2 nut sys 2 Dec 18 15:26 input@5
crw------
1 root root 198, 2 Jan 15 17:01 input@5:50d.751.cntrl0
crw------- 1 root root 198, 3 Dec 18 16:07 input@5:50d.751.cntrl0stat
crw------- 1 root root 198, 1 Dec 18 16:07 input@5:50d.751.devstat
crw------- 1 root root 198, 4 Dec 18 16:07 input@5:50d.751.if0in1
crw------- 1 root root 198, 5 Dec 18 16:07 input@5:50d.751.if0in1stat

The USB device was linked to the ugen driver with the following command:
add_drv -i '"usb50d,751.1"' -m '* 0666 nut sys' ugen

The /etc/minor_perm file contains the entry:
ugen:* 0666 nut sys

The file /etc/driver_aliases contains the entry:
ugen "usb50d,751.1"

The problem is that the child device entries created by ugen are not inheriting the permissions of the parent device, "input@5".
This, in turn, prevents my service running as the user "nut" from being able to access the device.

My ugly workaround is to execute "chown nut:sys /devices/pci@0,0/pci15d9,803@1d/hub@1/input@5*" at each service start, which clearly breaks the ability to move the device from one usb port to another.

History

#1

Updated by Warren V almost 5 years ago

Also, I'm not sure why input@5 is being mounted as 755, instead of 666. The only minor_perm entry with 755 is for the glb driver.
Is add_drv setting the ownership but ignoring permissions entries? I've noticed that other usb devices are also defaulting to these permissions, regardless of driver:

root@sanbox:/devices/pci@0,0/pci15d9,803@1a/hub@1/hub@3# ls al
total 7
drwxr-xr-x 3 root sys 10 Dec 16 20:14 .
drwxr-xr-x 3 root sys 3 Dec 16 20:14 ..
drwxr-xr-x 4 root sys 6 Dec 16 20:14 device@1
crw------
1 root root 191, 2 Dec 17 14:09 device@1:557.2419.cntrl0
crw------- 1 root root 191, 3 Dec 16 20:14 device@1:557.2419.cntrl0stat
crw------- 1 root root 191, 1 Dec 16 20:14 device@1:557.2419.devstat
crw------- 1 root root 191, 4 Dec 16 20:14 device@1:557.2419.if0in1
crw------- 1 root root 191, 5 Dec 16 20:14 device@1:557.2419.if0in1stat
crw------- 1 root root 191, 6 Dec 16 20:14 device@1:557.2419.if1in2
crw------- 1 root root 191, 7 Dec 16 20:14 device@1:557.2419.if1in2stat
crw------- 1 root sys 191, 0 Jan 15 16:31 device@1:usb_mid

#2

Updated by Warren V almost 5 years ago

I've eliminated at least one possible source of issues by making the following change to /etc/logindevperm:

#/dev/vt/console_user 0600 /dev/usb/[0-9a-f]+[.][0-9a-f]+/[0-9]+/* driver=scsa2usb,usb_mid,usbprn,ugen #libusb/ugen devices
/dev/vt/console_user 0600 /dev/usb/[0-9a-f]+[.][0-9a-f]+/[0-9]+/* driver=usb_mid,usbprn #Exclude storage and UPS

Also available in: Atom PDF