@pedronis can you please provide your opinion here?
We (some of the @reviewers) were discussing this request for some time today. On one side we provide a system-backup interface, but there are no restore capabilities available to support this use case. On the other side, granting write access to the various personal-files directories requested here not only allows for confinement escape, but also access to very personal or even sensitive information that can be store in those locations.
Even though the requested directories are limited, this looks like a classic confinement request (but backup/restore capabilities are not a supported category).
As @emitorino hinted, we have discussed whether using classic for this would give a better signal that this can escape confinement. Thereâs been varying opinion (it is not an explicitly mentioned category in the classic process page, see also restic discussion) whether classic is appropriate for backup applications but in is generally true that during restore many such applications will need to be able to write to places that allow them to escape confinement. The main reason to pursue a confinement route would be for cases where Ubuntu Core is the desired installation target. Classic also needs vetting. It also true that for desktop a combination of read permission and in-progress prompting support on write might cover some backup cases, this approach is not immediately available though.
Allow this to only open-source snaps(so that anyone can verify it)
Allow auto-connect only if the app upstream/developer confirms by showing their code that they donât write to those folders directly.
Neither of these work because once the developer has permission, a bad actor could publish a proprietary opaque application under the same name.
With every new release, the maintainers must create a post in forum asking continuation of the autoconnection and if they donât after a week, revoke the auto-connection. Thus, malicious changes done in new releases, canât be pushed to the users.
The platform doesnât allow for that, and would need significant design and development work to make it happen. So basically wonât happen.
Further, it places additional load on the review team. This conversation is already 2+ months old. Imagine that every time you do an update.
Backup apps should be given some space. This app falls into that category as it takes backup of the current desktop. If an app can qualify even for the classic confinement, why not this.
Contentious opinion - Not everything has to be a snap.
This snap will mainly help users with LTS releases and other distros that doesnât ship the latest gtk4 libraries. Can this snap be given access to at least allow the app to be in the store, with the plugs not auto connected on installation, but can be manually connected? Because not everyone will need every folder. Like someone from gnome will not need $HOME/.cinnamon, $HOME/.xfce and vice-e-versa. Itâll be great if this is allowed. @vikdevelop whatâs your take about this?
@reviewers have discussed this offline and have agreed that we will treat this like a classic snap. We have decided to grant auto-connect to the personal-files interface.
Could you please adjust the snap yaml to partition the dot-folders interface into individual groupings based on requested path. i.e