To make the review of your request easier, please use the following template to provide all the required details and also include any other information that may be relevant.
name: loar
description: LoAr (Local Archive Utility) is a lightweight CLI tool written in Rust, designed to intelligently scan, detect, and back up git-ignored or local-only files (such as .env, API keys, certificates, etc.) and folders scattered across your system into a single backup destination safely and efficiently.
Did you have a look at the system-backup interface that was explicitly designed for backup tools under strict confinement (and is already used by a few exiting backup tools in the store in strict confinement) ?
I would like to clarify why the `system-backup` interface and `strict` confinement are not sufficient for `loar`:
1. Write Access for Backup & Restore:
The `system-backup` interface provides only read-only access to the host system. `loar` needs to write/delete backup archives at the target destination (which can be a custom local directory or mounted drive) and, more importantly, needs write access to the host filesystem to perform restore operations.
2. Access to Dotfiles/Hidden Files under current user’s ownnership (.env, keys, certs):
Even if we were to use the `home` interface under strict confinement, snapd blocks access to top-level hidden files and directories (dotfiles) in the home directory to protect user privacy. However, the core feature of `loar` is to scan and back up local development project folders, specifically targeting git-ignored or local-only files (such as `.env`, API keys, and local TLS certificates), many of which are marked as hidden or reside inside hidden folders.
3. Precedents of Other Backup Tools:
Because of these inherent limitations of strict confinement on backup utilities, other major backup tools in the Snap Store (such as `restic`, and `duplicity`) are published under `classic` confinement. `loar` operates under the exact same technical constraints and requirements as these tools.
For these reasons, `loar` cannot function under strict confinement, and we would greatly appreciate your approval for `classic` confinement.
Thanks for the detailed follow-up. Unfortunately the category question @ogra raised is the blocking issue here: backup tools are not in the list of supported categories for classic confinement, and requests outside those categories cannot be granted through the normal process. So I think classic is not something we can approve for loar regardless of the technical arguments.
That said, I would like to address the technical points, because I believe strict confinement covers your use case better than you might expect:
On write access: system-backup is indeed read-only, but it is intended for reading system paths. Writing archives to a destination is covered by the home interface (for destinations under the user’s home) and removable-media (for mounted drives under /media, /mnt and /run/media). Restore into the user’s home also works under home.
On hidden files: the home interface only excludes top-level hidden entries in $HOME. Files like ~/projects/myapp/.env or hidden directories nested inside regular project folders are fully readable and writable with plain home, since the restriction applies only at the first path component. This covers the core use case you describe (git-ignored files in development project folders). If you need specific top-level dotfiles such as ~/.aws or ~/.kube, the personal-files interface exists for exactly that and is reviewed per-path.
My suggestion would be to package loar strictly with home and removable-media (and personal-files for any specific top-level dotfiles you can enumerate).
Thank you very much for your prompt and detailed assistance.
As suggested, I have updated the snap configuration to use strict confinement (plugging home, removable-media, and password-manager-service) and successfully released it to the stable channel.
If we find the need for any additional permissions (such as `personal-files` for accessing specific top-level dotfiles) in the future as the project evolves, I will visit the forum and request them again.
