Plugdev User gets Permission Denied on Raspberry Pi

[fabrykato]

trafficstars

Hi,

Scenario

• Raspberry Pi 4B controls a custom hardware and therefore ejects, updates and injects its SD card via usbsdmux device
• On Raspberry Pi the udev rules are applied as described in this project's docs
• udev rules are working basically, the /dev/sg0 device is owned by root:plugdev when rules get applied manually or after restart
• The pi user is also in the plugdev group

System Information

# cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

# cat /proc/cpuinfo
Model           : Raspberry Pi 4 Model B Rev 1.5

Error

Traceback (most recent call last):
  File "/home/pi/.cache/pypoetry/virtualenvs/xyz-3AExdpnY-py3.9/bin/usbsdmux", line 8, in <module>
    sys.exit(main())
  File "/home/pi/.cache/pypoetry/virtualenvs/xyz-3AExdpnY-py3.9/lib/python3.9/site-packages/usbsdmux/__main__.py", line 80, in main
    ctl = autoselect_driver(args.sg)
  File "/home/pi/.cache/pypoetry/virtualenvs/xyz-3AExdpnY-py3.9/lib/python3.9/site-packages/usbsdmux/usbsdmux.py", line 48, in autoselect_driver
    with open(model_filename, "r") as fh:
PermissionError: [Errno 13] Permission denied: '/sys/class/scsi_generic/sg0/device/model'

Context and Explanation

The udev rules provide no access to /sys/class/scsi_generic/sg0/device/model, its owned by root:root, so user space access can't work like that. At least for the symbolic links as described in documentation they are also owned by root:root, but I found that this is possibly correct on linux systems (see here). Documentation:

$ ls -l /dev/usb-sd-mux/
total 0
lrwxrwxrwx 1 root plugdev 6 Mar 31 11:21 id-000000000042 -> ../sg3
lrwxrwxrwx 1 root plugdev 6 Mar 27 00:33 id-000000000078 -> ../sg2
lrwxrwxrwx 1 root plugdev 6 Mar 24 09:51 id-000000000378 -> ../sg1

On my Raspberry Pi:

$ ls -l /dev/usb-sd-mux/
total 0
lrwxrwxrwx 1 root root 6 Mar 27 23:20 id-000000002002 -> ../sg0

Possible Solutions

• Maybe the udev rules should ensure that the plugdev group has permissions on relevant files, but it doesn't, at least for the PI
• I'd think there need to be another, maybe more manual option to select the correct driver for the device, but preferred would an automated selection, as implementation tries to provide.
• I didn't check yet if there are more things in code like this, otherwise I could imagine to workaround the main() and call the necessary stuff myself from my python scripts, but this package looks like your not interested in providing it as package than as binary program. So I'm not sure, if my workaround would be broken pretty soon. Do you follow the SemVer with your internally used API called from main()?

May you help me with this?

[Bastian-Krause]

Error

Traceback (most recent call last):
  File "/home/pi/.cache/pypoetry/virtualenvs/xyz-3AExdpnY-py3.9/bin/usbsdmux", line 8, in <module>
    sys.exit(main())
  File "/home/pi/.cache/pypoetry/virtualenvs/xyz-3AExdpnY-py3.9/lib/python3.9/site-packages/usbsdmux/__main__.py", line 80, in main
    ctl = autoselect_driver(args.sg)
  File "/home/pi/.cache/pypoetry/virtualenvs/xyz-3AExdpnY-py3.9/lib/python3.9/site-packages/usbsdmux/usbsdmux.py", line 48, in autoselect_driver
    with open(model_filename, "r") as fh:
PermissionError: [Errno 13] Permission denied: '/sys/class/scsi_generic/sg0/device/model'

Context and Explanation

The udev rules provide no access to /sys/class/scsi_generic/sg0/device/model, its owned by root:root, so user space access can't work like that.

That's not correct. On all systems (including a Raspberry Pi) I could get a hold of, others can read that file:

-r--r--r-- 1 root root 4.0K Apr 2 10:57 /sys/class/scsi_generic/sg0/device/model

At least for the symbolic links as described in documentation they are also owned by root:root, but I found that this is possibly correct on linux systems (see here). Documentation:

$ ls -l /dev/usb-sd-mux/
total 0
lrwxrwxrwx 1 root plugdev 6 Mar 31 11:21 id-000000000042 -> ../sg3
lrwxrwxrwx 1 root plugdev 6 Mar 27 00:33 id-000000000078 -> ../sg2
lrwxrwxrwx 1 root plugdev 6 Mar 24 09:51 id-000000000378 -> ../sg1

On my Raspberry Pi:

$ ls -l /dev/usb-sd-mux/
total 0
lrwxrwxrwx 1 root root 6 Mar 27 23:20 id-000000002002 -> ../sg0

The permissions of the symlinks are not an issue.

[SmithChart]

Hey @Fabi89, any news on this?

[fabrykato]

Hi, thanks for your reply. After @Bastian-Krause replied, I checked if I can make it work, but couldn't yet. Probably the RPi is a little misconfigured or it's little outdated OS is the key. We are running it in the next days on a fresh installed RPi 5 and I'll see, if it works out of the box there. Will come back to this soon.

[fabrykato]

Hi, since there is some hardware missing, I could not check yet on new RPi 5 setup.

New Findings

Nevertheless, I have news on this:

• When I remove and insert the USB SD Mux while RPi 4 is running, it works as expected (no sudo required, cat /sys/class/scsi_generic/sg0/device/model prints model, get and dut works). Obviously, I did not try that before.
• Always, when I reboot the RPi, it seems to have problems to load the USB SD Mux device (happened in a similar way with a newly added USB ethernet adapter)
• With additionally attached USB devices, after rebooting I don't have permission denied problems anymore, instead the USB SD Mux is not loaded at all (no /dev/sg* device, but listed with SerialNumber: 000000002002 in dmesg)
• It works with physical ejecting the USB SD Mux device as well as running echo "1-1.1.1" > /sys/bus/usb/drivers/usb/unbind ; echo "1-1.1.1" > /sys/bus/usb/drivers/usb/bind as root user, so I could setup a more or less strange systemd service to fix this

I am not fully convinced, that the problem is completely specific to my setup and that others won't run into this (at least when running with multiple USB devices on a RPi). So, I'd like to know, what you think about this.

Additional Information

When I reboot the RPi, the device doesn't work at all now (pi user in plugdev group):

$ ls -lisa /dev/usb-sd-mux/id-000000002002                                                                                                                           
ls: cannot access '/dev/usb-sd-mux/id-000000002002': No such file or directory
$ dmesg | less
...
[    2.751009] usb 1-1.1.1: new high-speed USB device number 5 using xhci_hcd
[    2.908076] usb 1-1.1.1: New USB device found, idVendor=0424, idProduct=4041, bcdDevice= 2.09
[    2.908113] usb 1-1.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.908138] usb 1-1.1.1: Product: usb-sd-mux_rev4.0
[    2.908152] usb 1-1.1.1: Manufacturer: Linux Automation GmbH
[    2.908165] usb 1-1.1.1: SerialNumber: 000000002002
...

When device works, I get the following output:

$ poetry show usbsdmux
 name         : usbsdmux
 version      : 24.1.1
 description  : Tool to control an usb-sd-mux from the command line
$ ls -l /dev/usb-sd-mux/
total 0
lrwxrwxrwx 1 root root 6 Apr 26 10:36 id-000000002002 -> ../sg0
$ dmesg | less
...
[  175.541698] usb 1-1.1: USB disconnect, device number 3
[  175.541734] usb 1-1.1.1: USB disconnect, device number 5
[  179.603796] usb 1-1.1: new high-speed USB device number 17 using xhci_hcd
[  179.704136] usb 1-1.1: New USB device found, idVendor=0424, idProduct=2640, bcdDevice= 8.a2
[  179.704164] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  179.706026] hub 1-1.1:1.0: USB hub found
[  179.706147] hub 1-1.1:1.0: 1 port detected
[  179.991770] usb 1-1.1.1: new high-speed USB device number 18 using xhci_hcd
[  180.148674] usb 1-1.1.1: New USB device found, idVendor=0424, idProduct=4041, bcdDevice= 2.09
[  180.148691] usb 1-1.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  180.148698] usb 1-1.1.1: Product: usb-sd-mux_rev4.0
[  180.148703] usb 1-1.1.1: Manufacturer: Linux Automation GmbH
[  180.148707] usb 1-1.1.1: SerialNumber: 000000002002
[  180.150589] usb-storage 1-1.1.1:1.0: USB Mass Storage device detected
[  180.150946] scsi host0: usb-storage 1-1.1.1:1.0
[  181.152598] scsi 0:0:0:0: Direct-Access     LinuxAut sdmux HS-SD/MMC  2.09 PQ: 0 ANSI: 0
[  181.154965] sd 0:0:0:0: [sda] Media removed, stopped polling
[  181.155759] sd 0:0:0:0: [sda] Attached SCSI removable disk
[  181.168622] sd 0:0:0:0: Attached scsi generic sg0 type 0
...
$ cat /sys/class/scsi_generic/sg0/device/model
sdmux HS-SD/MMC
$ $(poetry env info --path)/bin/usbsdmux /dev/sg0 get
off
$ $(poetry env info --path)/bin/usbsdmux /dev/sg0 dut
$(poetry env info --path)/bin/usbsdmux /dev/sg0 get
dut

The changes I did in the meantime to get new findings:

• Shutdown (once again, shouldn't have been the problem originally)
• Install an additional J-Link debugger as RPi USB-Device
• Install an additional ethernet adapter as RPi USB-Device
• Restart
• Physically eject and inject the USB SD Mux as it was not loaded correctly (no /dev/sg0 and no ID-based symlink)

[jluebbe]

Which modules are loaded when it doesn't work (lsmod | grep sg)? If 'sg' is missing, then something is broken with udev coldplug. You can add sg to /etc/modules as a workaround.

[fabrykato]

Which modules are loaded when it doesn't work (lsmod | grep sg)? If 'sg' is missing, then something is broken with udev coldplug. You can add sg to /etc/modules as a workaround.

I forgot to check what you requested before working on this again. Now I can confirm that there is no problem with your software, but there was one with our setup on the RPi. Maybe it helps others: I had some hard time determining a smooth working USB port layout for all the devices attached to the RPi4. For me the on-board USB2 ports didn't work as reliable as I expected on the RPi when using all 4 ports (including one USB3 port attached to a 7-port USB hub with 6 ports in use). The solution for me was to use mainly the USB3 ports, both attached to hubs (the one active USB3 7-port hub and one passive USB3 4-port hub) and one of the USB2 ports used for a debugger, while one onboard USB2 ports remains completely unused. Sadly, it's a try and error solution. I'll close this now. Thanks for your support.