moraine takes hard-linked snapshots of user-selected paths to a NAS/server over SSH (rsync) or to cloud/FTP/SMB/WebDAV/S3/Drive via rclone, and restores whole snapshots or individual files. This snap ships the command-line client only (the GTK desktop build is distributed as a Flatpak/AppImage/.deb elsewhere), with rsync, the OpenSSH client and rclone bundled so every backend works out of the box.
Why classic confinement is required
A backup tool has to read whatever paths the user points it at, and that set is chosen at runtime — it cannot be known or enumerated in advance. Under strict confinement:
The home interface grants “access to non-hidden files in the home directory.” Its AppArmor rule is owner @{HOME}/[^s.]** rwkl, which excludes every top-level dotfile. But the highest-value things to back up are exactly those — ~/.ssh, ~/.gnupg, ~/.config, ~/.gitconfig, ~/.mozilla, ~/.thunderbird: the configuration and keys a backup exists to protect. Six of the eleven default source locations moraine suggests on Linux are top-level dotfiles; a backup that silently skips them is worse than none.
personal-files / system-files cannot close the gap: they declare named paths (one store request per path), whereas moraine’s source set is whatever the user chooses. There is no fixed list to declare.
Scheduling installs entries into the user’s crontab, which strict confinement also denies.
- rsync/ssh/rclone run as helpers against arbitrary local sources and arbitrary remote destinations.
Taken together, the core function — “back up the paths I choose, including my dotfiles, on a schedule” — cannot be delivered under strict confinement or the current interface set, which is why the snap declares confinement: classic.
Happy to answer questions or adjust anything. Thanks for reviewing!
It is plausible that there are technical reasons why this snap needs classic to work properly in all scenarios, but please note that classic confinement is a sensitive matter and it is reserved for mature, well-known applications published by mature, well-known entities. As of today, I believe that this snap doesn’t meet this criteria because of the following reasons:
The project seems to be very fresh, according to the upstream repository
The projects seems to have little/none community around according to upstream repository (contributors, issues, PRs, etc.)
I could not find evidences that the project has a strong enough user base currently
Thus, considering these factors, I think this snap should not get classic confinement as of now.
Thanks both — that’s fair, and the system-backup pointer is exactly what I was missing.
On the apparent contradiction: both lines are true, and your suggestion actually reconciles them. moraine recommend proposes a fixed default set of sources on Linux (the eleven locations, six of them top-level dotfiles), that part is knowable and declarable. But the tool also lets the user back up any path they choose beyond that set, which is the “no fixed list” part. So personal-files (read-only) for the default dotfiles + home/removable-media for the common case, and system-backup for the arbitrary-path / whole-system case.
I’m reworking the snap to strict on that basis (dropping the classic request), and happy to ship it with manual snap connect for the privileged plugs rather than ask for auto-connect for now, that also sidesteps the maturity concern, and I can revisit auto-connect as the project grows.
Two practical questions before I publish:
Arbitrary paths via system-backup. As I understand it the host root is read-only at /var/lib/snapd/hostfs, so a source outside $HOME would be addressed as /var/lib/snapd/hostfs/etc/… Is prefixing user-supplied paths with the hostfs root the expected UX for a backup tool, or is there a cleaner pattern? (Home + dotfiles I’ll keep at their real paths.)
2. Scheduling. The tool normally installs a cron entry per schedule, which strict denies. My plan is to drop in-app scheduling in the snap and document a host systemd timer / cron running snap run moraine backup instead. Is that what other backup snaps do, or is a snap daemon + timer preferred?
Thanks again for steering me to the right interfaces.
For 1) your understanding is correct, you need to use the prefix (and likely want to hide it in the UI)
For 2) snaps do support systemd timers (I haven’t touched that feature for a while so I forgot if/how you could dynamically change them), I’d look there first before patching the feature out
I’ll ship a strict snap now for the common case: home directory, dotfiles via personal-files, and removable media, all at their real paths (so no hostfs prefix is needed there), scheduled from a host systemd timer / cron running snap run moraine backup.
Whole-system paths via system-backup, with the hostfs prefix hidden in the UI, per your tip and in-snap scheduling via snap timers, I’ll add in a follow-up release once the app-side path handling is in.