Libusb application can't access device even after the raw-usb interface is connected

snapcraft
1

It can enumerate them, however, an attempt to open the device fails for no reason.

$ uuu -lsusb
uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.4.95-0-g38dc325

Connected Known USB Devices
        Path     Chip    Pro     Vid     Pid     BcdVersion
        ==================================================
        1:4      MX6SL   SDP:    0x15A2 0x0063   0x0001

$ uuu -V recover.uuu
uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.4.95-0-g38dc325

Build in config:
        Pctl     Chip            Vid     Pid     BcdVersion
        ==================================================
        SDPS:    MX8QXP          0x1fc9  0x012f  [0x0002..0xffff]

        (stripped)

        FB:                      0x3016  0x0001
Wait for Known USB Device Appear...
 3月 03 03:38:24 hostname kernel: audit: type=1400 audit(1614713904.123:205): apparmor="DENIED" operation="open" profile="snap.universal-update-utility.universal-update-utility" name="/snap/core/10823/usr/share/locale/zh_TW/LC_MESSAGES/snappy.mo" pid=50527 comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
New USB Device Attached at 1:4
libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/001/008: Permission denied
libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes.
1:4>Fail Failure open usb device,Try sudo uuu(1.01s)
2

Is the user you’re running the command as have write access to the device node? Absent any udev rules to change ownership/permissions, I wouldn’t normally expect non-root users to be able to open arbitrary USB devices.

3

Is the user you’re running the command as have write access to the device node?

No, the permission is 0660.

I will expect the connection to the interface should grant permission regardless of its Unix file permission (as the documentation suggests).

Is running the snap command as root the solution?

4

Why would you expected a snapped version of the application to have greater access to the system than a non-sandboxed version of the application?

If the utility is usually run as root, then it isn’t necessarily bad that the snapped version would need to be too. If it was intended to be run as a regular user, then presumably it would come with some udev rules to grant permission to that particular device type.

1 Like
5

I assumed there’s some kind of magic occurred in snapd that makes this possible :man_shrugging:.

I can successfully access the device after running the command as root, but encountered another problem: The snap can no longer access regular files under my user directory (assumed due to the $USER is now root, which makes my home directory out of the sandbox). As this behavior is clearly inconsistent with classic applications(which root can access everything) is there any way to workaround this issue?

EDIT: No longer a problem: https://forum.snapcraft.io/t/libusb-application-cant-access-device-even-after-the-raw-usb-interface-is-connected/23069/10

brlin@brlin-musicha-mz-530:~/ddvk-remarkable-uuuflash$ sudo uuu recover.uuu
uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.4.95-0-g38dc325

Wait for Known USB Device Appear...
Error: fail open file: >recover.uuu
6

you could split the app in two halves … a socket activated daemon and a client app …

7

I’m not really the developer of the application :man_shrugging:, making/proposing an architectural change is not really feasible IMO.

If it’s technically possible I would like to propose to extend the home interface’s confinement to cover $SUDO_USER’s home directory when the snap application is run by a sudoer. This should satisfy most use-cases without exposing all filesystem to the application.

8

I’ve updated the documentation:

NOTE: The use of this interface only extends the snapd’s own sandbox confinement, it will NOT supersede the classic Unix file permission model so the user still needs to have sufficient r or w permission to the device node by either run the snap command as root or have a designated udev rule that grants the permission.

1 Like
9

I’ve updated the home interface’s documentation regarding this behavior, feel free to improve it.

1 Like
10

Yes, you would need to use the read: all property with the home interface plug if you want to read non-root files when running your snap as root.

1 Like
11

Missed that one, I’ll give it a shot.

I also reverted the documentation which is not broken in the first place.

12

We do plan on having some day such magic, that is detailed in Multiple users and groups in snaps, but that work is not yet started (to provide a snap access to a device while not being root)

1 Like
13

Looking at the documentation for the tool, it documents what you’d need to do to run it as a regular user, under the heading “How to avoid sudo in linux”:

Those changes should be applicable to your snap too. Maybe point users of your snap at that piece of documentation?

1 Like
14

Although manually applying the udev rules works it isn’t an out-of-box experience IMO. Still, it is helpful nevertheless.

It would be preferable if snapd supports automatically applying specified USB VID/PIDs allow udev rules when the snap is ran…

15

Right. The non-snapped version of the tool doesn’t offer an out-of-the-box experience for unprivileged use either though.

16

That’s fair, however, since classic packaging distribution(deb, rpm) of the same category of applications do ship udev rules to enable unprivileged use (e.g. adb) I expect snaps is also eligible for such mechanism.

$ dpkg-query --listfiles android-sdk-platform-tools-common | grep udev/rules.d/
/lib/udev/rules.d/51-android.rules

$ tail -n5 /lib/udev/rules.d/51-android.rules

# Enable device as a user device if found
ENV{adb_user}=="yes", MODE="0660", GROUP="plugdev", TAG+="uaccess"

LABEL="android_usb_rules_end"