@d1plo1d - your response is required to proceed with this request. Thanks
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.
I’ve added hardware-observe , gpio , and gpio-memory-control but there appears to be a problem opening the serial port:
= AppArmor =
Time: Apr 04 08:11:29
Log: apparmor="DENIED" operation="open" profile="snap.tegh.tegh" name="/dev/ttyUSB0" pid=390 comm="tegh" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
File: /dev/ttyUSB0 (write)
Suggestions:
* add 'raw-usb' to 'plugs'
* add 'serial-port (with gadget or core support)' to 'plugs'
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.
If you want to take a look my snapfile is here: https://github.com/tegh/tegh/blob/7f488b18b7ffb8047d7e65803b7e4b0ec49ca28d/snap/snapcraft.yaml
I’m not sure what else to try. Any advice is very much appreciated. Thanks!
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.
1 Like
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:
apps:
tegh:
plugs:
- network
- network-bind
- process-control
- hardware-observe
- raw-usb
- gpio
- gpio-memory-control
That sounds ideal. +1 to that.
Since raw-usb did not appear to resolve the issue is there anything else we can try or should we move forward with classic confinement?
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))
Possibly not. How do I configure the user/groups that the snap’d daemon gets run with?
you dont …
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.
That’s a great point. I have not tried Ubuntu Core yet myself but I would love for Tegh to be able to run on Ubuntu Core.
The only reason I would want classic confinement would be if all other options were exhausted.
Regarding Octoprint: that’s it exactly. Octoprint has been a major inspiration for Tegh.
But getting back to snapcraft:
if your snap runs as a daemon it is run as root inside strict confinement
Tegh is run as a daemon so it would be the root user inside confinement. So I’m guessing I could do that with something like:
usermod -a -G dialout root
in a install hook but that does not appear to be adding the user to the group for some reason. Any idea why it wouldn’t work?
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
1 Like
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.
Wait, I was installing the snap with --devmode. Removing devmode is giving me different results.
Now I’m getting:
- Run install hook of "tegh" snap if present (run hook "install": /snap/tegh/x1/meta/hooks/install: line 13: /usr/sbin/usermod: Permission denied)
and:
Log: apparmor="DENIED" operation="exec" profile="snap.tegh.hook.install" name="/usr/sbin/usermod" pid=24096 comm="install" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
Log: apparmor="DENIED" operation="open" profile="snap.tegh.hook.install" name="/usr/sbin/usermod" pid=24096 comm="install" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
It would work if I could run it as sudo but trying to use sudo gets me:
Log: apparmor="DENIED" operation="exec" profile="snap.tegh.hook.install" name="/usr/bin/sudo" pid=21996 comm="install" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
Log: apparmor="DENIED" operation="open" profile="snap.tegh.hook.install" name="/usr/bin/sudo" pid=21996 comm="install" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
@ogra how does the octoprint snap solve this? Wouldn’t they also need to add the confinement root user to dialout?
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?
1 Like
the octoprint snap does not solve it currently because it refuses to even start as root (so you can not use it as a daemon at all until Phase 1 of 'Opt-in per-snap users/groups' (aka, the 'daemon' user) has landed … )
but your appliactio seems to be able to run as root so you should not need to do anything, if your app starts as a daemon it should a) be running as root and thus have full access to the serial device (like jamie said above) … or if you run the app as a user and the user is in the dialout group it should have full access (same should go for running the app via sudo)
I’m removing this from our review queue due to lack of information. When you have a chance to get back to us, just respond here.
Thanks @jdstrand. I’m juggling a few things at the moment and unfortunately just haven’t had the time to try out the suggestions here. I appreciate all the help from everyone though - I would be totally lost in this otherwise! I’ll give y’all a shout once I have time to devote to debugging snap permissions again.
Cheers,
Rob