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.
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.
I assumed there’s some kind of magic occurred in snapd that makes this possible .
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?
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
I’m not really the developer of the application , 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.
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.
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)
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?
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.
$ 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"