Hello! I’m the maintainer of Déjà Dup, a general purpose GNOME backup tool.
https://wiki.gnome.org/Apps/DejaDup https://gitlab.gnome.org/World/deja-dup
It would ideally have read/write access to any file on the system for backing up / restoring purposes. So classic seems like a good fit to me.
The :system-files and :personal-files interfaces don’t seem suited for this usage pattern (like, I can’t just specify :system-files of ‘/’ and get access to everything 
)
Thanks!
Hi @mikix
I recently submitted https://github.com/snapcore/snapd/pull/6436 to support backup applications (it is undergoing review and iterations). Would this interface (and other existing interfaces) be sufficient for your needs?
/me waves
Yes, I would prefer to be a confined app if possible and that interface would be half of the story.
Backup is one half, restoring is the other. Ideally I’d also have write access to the same set of files.
Is that something that could be added to the system backup interface? Or at that point is there no meaningful distinction between classic and can-write-everywhere?
Ah, restore. There is very little difference if you need write access to the entire system. Remind me, is deja-dup about full system backups or user data backups (I see only the session dbus service locally, which suggests the latter).
It emphasizes user data backups (defaulting to just backing up $HOME).
But it allows backing up and restoring system files too, as a supported-but-less-important use case. (It will prompt for access via policykit if needed when restoring – another thing unlikely to work in the confined space.)
So. Classic mode would be the easiest “no feature loss” path for me. But confined read-system/write-home access could be another path. It’s not my preference to offer a less featureful version via snaps (mostly because I’d have to add some code to handle what to present to the user in that case), but I’m certainly open to an argument that more classic snaps in the world is also a bad thing.
There is precedent for backup applications to use classic and the request is understood. There is also a discussion about how to expose polkit that is happening here: Allow snapped daemons to use polkit authorisation
The requirements are understood and I’ve vetted the publisher. Granting use of classic. This is now live.
@mikix - fyi, you can either upload a new revision of your snap and it should pass automated review or you can request a manual review via the store for the existing revision.
Thank you! I appreciate the quick turnaround.
So I was toying with the idea of restricting the snap to $HOME backups and restores.
(Classic confinement is increasingly locking me out of the “normal” way to do things with desktop-launchers, gnome extensions, and content interfaces in general.)
But I couldn’t find a suitable interface for it. home disallows dot-file and ~/snap/ access. personal-files doesn’t let you specify just $HOME.
I’d like to be able to see everything in a user’s home (and also have gvfs access, which is something that home tries to handle too, it looks like).
No action requested here, just mentioning an interface gap that is keeping me on classic confinement.
https://github.com/snapcore/snapd/pull/6436 is coming that will give you access to all of hostfs (except /proc, /sys and /dev). This is read-only though.
Hello! Please file an issue report on the upstream tracker. I can respond and help there.
I’ve not heard of that crash! Would be good to fix. When you post, please mention which release of Mint you’re on.
