I’m trying to publish Tegh Beta. Tegh is a new 3D printer networking software for USB Serial 3D Printers which we aim to launch with the Snap Store.
A design goal of Tegh is ease of setup for the user and so a straightforward installation is integral to that vision.
Tegh needs classic confinement so that the user can list and choose the serial device of their 3D printer from a drop down list in the web UI. To do that we need access to a list of all USB serial devices.
The relevant source for listing USB serial ports and watching for changes to that list can be found here:
Tegh also requires classic confinement to enable control of the Raspberry Pi GPIOs. Raspberry Pi GPIOs allows users to configure and control non-realtime 3D printer accessories such as lights, fans or motors without having to modify their 3D printer firmware.
The relevant source for configuring and controlling the Raspberry Pi GPIO can be found here:
Thanks @jdstrand and @lucyllewy. I’ve had to prioritise other work on Tegh for the moment but if we can leave this open I will get back to you as soon as I have a chance to look into @lucyllewy’s suggestions.
The serial port Tegh uses is chosen by the user in Tegh’s web UI so as I understand it Tegh does not fit a serialport gadget snap since serialport gadget snaps require the serial port to be specified ahead of time in the snap’s configuration.
There is a serial-port interface but it is currently not connectable on classic distributions. Once the serial-port interface is updated for dynamic hotplugging, you will be able to use the serial-port interface in your snap.
In the meantime, you can also plug raw-usb. Please try that and respond back with your findings (once that is done, the requirements should be understood and we can proceed with the request or consider auto-connections for your snap.
raw-usb is already in my snapcraft.yml. I’m not sure why the error suggests to add raw-usb given that I already have it. Here’s my list of plugs for Tegh:
is your user in the dialout group ? (despite interfaces, normal linux filesystem permissions still apply (i’m not sure if the review tools make a difference between simple file access denials or interface induced access restrictions))
if your snap runs as a daemon it is run as root inside strict confinement …
if your snap is a user-executable app it runs under the credentials of the user who started it (with all filesystem permissions/denials such a user has).
if your snap falls into the latter category, you can check with the groups command if you are in the dialout group … if you are, my comment is moot since your user should have access to the device …
some other side-thought here:
did you consider that people will probably want to run your software inside a headless/user-less Ubuntu Core appliance ? for my 3D printer i run an Ubuntu Core image with octoprint on a Pi to control the printer and i think this is a very typical use-case for software like tegh (your description sounds actually pretty similar to octoprint)… classic confined snaps are not installable on Ubuntu Core for obvious security reasons, so going for classic means you are killing this opportunity for your software.
I imagine this failed because snap confinement doesn’t allow snaps to modify or create users. You could try looking in the logs with journalctl -ef and see if there’s anything in there about your snap being denied permission to edit /etc/group or /etc/passwd.
In general, if your snap needs to modify users and groups you may need to wait for the implementation discussed at Multiple users and groups in snaps
I am not seeing any issues with assigning the group. But this is weird: after I install my snap locally my root user (outside confinement) is in the dialout group and my confinement root still does not have the dialout group. So it’s being added to the wrong user.
Unfortunately sudo will not help you there. The snap is confined using AppArmor, as you can see in the log messages you pasted, and the AppArmor policy doesn’t allow adding or modifying users from inside a snap.
First off, root does not need to be in the dialout group since traditional permissions allow root access to the device. Non-root users need to be in this group (or ACLs used) to access to the device. The snap is not in a position to grant this access either, except with the account-control interface and then only on Ubuntu Core. Also, strict mode snaps intentionally do not have the access for using sudo.
Today, the only way is for an admin user to grant the access manually, eg: sudo adduser <user> dialout, but again, the snap cannot do this. It is technically possible for snapd to provide a mechanism for snaps to request permission changes on specific files, but that needs design and isn’t currently on the roadmap.
There is a specification that deals with some of this here: use case 2. When that is implemented, it won’t give your snap the ability to add users or modify groups, but does allow for later work to build upon it, perhaps something that would allow a gadget to assign users to groups.
As for octoprint, I reviewed its snap.yaml and see nothing in its security policy that would allow the snap to change group memberships. Perhaps it detects the error and gives the user helpful feedback on the command to run to allow access for non-root users (this is what I suggest to you as well).
In terms of this request, when you plugs raw-usb, connect it and add your user to the dialout group, does your snap work? If not, are there security denials in the logs? If so, what are they?