This app needs to be able to update DNS settings on the OS since it opens a DNS53 to DOH (dns over https) proxy so I’m requesting a classic confinement. It executes sudo commands (to install, start, stop, uninstall system service), raises a local udp+tcp server and needs to update /etc/resolv.conf and a file in /etc/systemd/system/ since it spawns a service process.
Thank you.
To get your app running, have you tried using a snap daemon app configuration? Doing that will negate the requirement to access the systemd files in /etc.
To listen for DNS requests network-bind is sufficient, and to make outbound DOH requests network will be sufficient. To update the resolvers configuration the expected method is with the network-manager interface allowing access to configure systemd-resolvd.
Unfortunately this app is a wrapper on a different executable, more like a controller of that project which does not adhere to snap constraints. That’s a cross platform CLI project that sets up services, rewrites DNS configs and re-routes DNS queries. dnsadblock-desktop just provides a mere graphical interface to it.
To update the resolvers configuration the expected method is with the
network-managerinterface
The CLI app actually disables network manager’s (if it exists) resolv.conf management. We cannot rely on the fact that NetworkManager is even present on the system since that’s an utility app for desktops/GUI. Our service also needs to survive across restarts since that’s the promise to, and the expectation of, the user.
As described in Process for reviewing classic confinement snaps, the direct use of sudo and configuring systemd services are unsupported use cases for snaps and are not candidates for classic. I’m not familiar with the technical implementation of dnsadblock-desktop, but based on the description alone, opening a port, updating the resolver configuration and controlling network-manager is all supported via network-bind, network-control and network-manager. snapd also supports daemons in snaps so writing out systemd files is not required.
You mentioned that your snap just wraps something else that does these things, but, unfortunately, as documented in the aforementioned URL, this also isn’t justification for classic.
It sounds like your snap needs to be rearchitected a bit to work within the snap ecosystem. Without making these changes, your snap has many of the same characteristics of the unsupported “management snaps” category. You may want to visit and/or create new topics in the snapcraft category for helping transitioning away from classic.
One more question: is a snap daemon able to survive reboots and start when the host is back again?
