Classic confinment request for rclone-manager

store-requests classic-confinement
1

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.

I understand that strict confinement is generally preferred over classic.

I’ve tried the existing interfaces to make the snap to work under strict confinement.

Hello, I am the creator of RClone Manager.

I’m requesting classic confinement access to publish the rclone-manager snap.

RClone Manager acts as a comprehensive frontend and process manager for the rclone CLI tool. Due to the nature of navigating and managing arbitrary file systems and interacting with existing system binaries, sandboxing introduces severe limitations that degrade the user experience and break core functionality.

Reasoning

RClone Manager needs classic confinement primarily for two reasons that cannot be reliably satisfied by existing plugs:

1. Executing the user’s rclone binary The application locates and executes the user’s existing rclone installation to perform its core tasks. rclone can be installed in a variety of locations depending on the user’s preferred method:

  • rclone (apt/package managers)
  • /snap/bin/rclone (snap)
  • ~/.local/bin/rclone (manual installation)
  • /usr/local/bin/rclone (rclone’s official installer script)
  • Any custom user-defined $PATH location

Furthermore, if RClone Manager cannot find the standard binary automatically, the app prompts the user to either download it to a custom location or manually select an existing rclone executable anywhere on their system.

There is no single plug that grants execute access to arbitrary binaries across the entire filesystem. While the personal-files and system-files plugs could cover some known paths, they cannot gracefully handle custom installation paths, user-selected binary locations, or arbitrary download directories. Forcing users to reconfigure or move their binaries just to satisfy the GUI’s permissions would be a frustrating experience and breaks the core functionality of the app.

2. Arbitrary filesystem path access Because rclone operates on any directory the user chooses (local backup sources, active mount points, external drives, network shares, and paths well outside of $HOME like /mnt/data or /media/user/drive), Rclone Manager needs broad filesystem visibility.

While the home and removable-media plugs cover basic use cases, they fall significantly short for advanced users backing up NAS mounts, custom partitions, or server directories. Without classic confinement, directory browsing and auto-completion for local paths would yield incomplete or blocked results, fundamentally breaking what the user expects from a file management GUI.

Alternatives considered

  • Bundling rclone inside the snap: This solves binary access but fails to solve the arbitrary filesystem access issues. It also creates a fractured experience where users cannot utilize their globally configured existing rclone version, and it puts the burden on us to constantly sync updates with the bundled version.
  • Strict with personal-files/system-files: Would require hardcoding every potential rclone install path and would inevitably break for anyone using a custom location.
  • Strict with home + removable-media: Covers standard setups but breaks entirely when users try to manage backups for data on non-standard mount points (a very common scenario for rclone power users).
2

generally being for a general audience weight against making the snap classic

Given the vetting requirements for classic I would consider pursuing:

4

Not within the “mount namespace” but within the snaps filesystem space, your users would have to navigate to ~/snap/<snapname>/<mountpoint> this definitely works with every filemanager

You could ask your users to simply copy them to a place where the snap can execute them (again ~/snap/ was exactly designed for this)

If these are all hard required to even run your app, you would have to ship them inside your snap even when it is classic, snaps need to be able to run on any OS you install them, this is true for all snaps regardless which confinement model they use. For strictly confined snaps you have access to the gsettings database of the user via the gsettings interface, lsblock is accessible via the hardware-observe interface, access to anything xfconf-query would need is provideed through the x11 interface…

When you tested with strict confinement, did you use the snappy-debug tool ? It would have made all the suggestions (and likely a bunch more) I just made above …