Arbitrary file system access: Users need to upload/download files from ANY location on their filesystem, not just $HOME. The --dir parameter for sx-server allows serving from any directory (e.g., /data, /mnt/, /opt/, etc.)
SSH tunnel integration: The tools work through SSH reverse tunnels where users specify arbitrary local paths to transfer. Restricting to specific directories would break the core functionality.
Development tool workflow: Similar to tools like rsync, scp, or rclone, users expect to access their entire filesystem for transfers between local and remote machines.
I understand that strict confinement is generally preferred over classic.
I’ve tried the existing interfaces to make the snap work under strict confinement.
The home and removable-media interfaces are insufficient as users need to transfer files from system directories, project folders outside home, mounted drives, and other arbitrary locations as part of their development workflow.
I’m sorry, but how could this have been granted classic at all ? There is no supported category called “tools”, “Arbitrary file system access” is excplicitly not a criteria for classic and none of the listed directories would require classic either when using removable-media or a system-files interface…
Did we change our review policies or add a new category I have not seen on the review requirements page ?
Thank you for your concern. I’d like to clarify the reasoning for classic confinement:
Correction on category: You’re right that “tools” isn’t a standard category - I should have specified “utilities” in my original request. However, the core justification remains valid.
Arbitrary filesystem access is necessary: The sx-client specifically requires access to any user-specified directory because:
Download to any path - Users need to download files to arbitrary locations on remote servers (e.g., /var/www/html, /opt/configs, /srv/data, /etc/backup)
Upload from any path - Users upload files from system directories, mounted drives, project folders outside home
Real-world sysadmin workflows - Transferring config files from /etc, logs from /var/log, data from /srv, /opt, mounted network drives, etc.
Existing interfaces are insufficient for sx-client:
removable-media: Only covers /media and /mnt - doesn’t help with /var, /etc, /srv, /opt, etc.
system-files: Requires pre-defining specific paths, but sysadmins need to transfer files from ANY system location
home: Severely limits usefulness - most sysadmin file transfers involve system directories outside home
Similar tools precedent: Many established snaps use classic confinement for similar filesystem access needs:
code
pycharm-community
sublime-text
atom
kate
File managers, backup utilities, and other file transfer tools inherently need arbitrary filesystem access for professional workflows. SX serves the same category of system administration tools.
The fundamental purpose of SX is to transfer files between any locations across SSH sessions. Restricting filesystem access would break the core sysadmin workflow that the tool was designed to serve.
Heh, it is pretty clear why you want it, the problem here is just that we do not currently have a way to grant this under the existing requirements doc and the process for overriding usually needs to involve an architect to permit the override, which simply did not happen (and in case where we do this more often for similar apps we should add a new category to the requirements page, given this is the second such request, this should probably happen)
note that there is a specific category for IDEs and editors, all the apps you list are under that category (or under “cloud management” i.e. pycharm…)
File managers are explicitly excluded up to now, for backup tools we created an explicit interface to cover exactly that use case and avoid granting them classic … file transfer tools really do not need broader access than the user has him/herself and if so, should use the system-files interface to explicitly extend the allowed paths
Given that SX is fundamentally a server administration tool for managing files across remote systems and cloud infrastructure via SSH tunnels, would it fall under the existing “cloud management” category?
SX’s primary use case is sysadmins transferring files between local machines and remote servers/cloud instances. The system-files interface wouldn’t work for SX because sysadmins need to access arbitrary system paths (/var/log, /etc, /srv, /opt, mounted drives, etc.) that can’t be pre-defined - the entire value proposition is allowing administrators to transfer files from any location during server management tasks.
Arbitrary file access isn’t something that can’t be done, it’s something we decide not to do.
There’s a system-backup interface that gives read access to /var/lib/snapd/hostfs/, it’d hypothetically be better for us to make a similar interface that just removes the write restriction, so that then your strict snap CAN access any file on the filesystem, as long as it takes into account that quirk with the path.
if OS.GetEnv("snap") is not none:
path = "/var/lib/snapd/hostfs/" + path
Otherwise, things like .ssh keys are in interfaces already, and tools like SFTP can be bundled in strict.
There’s a few more reasons to prefer classic than just “the file system isn’t in a mount namespace”, because that mount namespace gives you advantages too, not just restrictions.
I’m not against this in principal balanced with developer checks, but I think Ogra’s position comes more from a technical correctness POV, plenty of us have snaps where arbitrary file access would remove bug reports, but we all usually get told simply no and to modify our documentation and tell our users to change, and it’s difficult longterm to tell some people no whilst telling other people yes.
It’s an intentionally flawed strawman argument, but why can’t Firefox just be made classic? I need to access /tmp. That’s the kind of questions that would become more common and harder to justify and why the categories exist.
Thank you for this insight, James. I now understand the policy consistency concerns.
If such a read/write interface were created, I’d be willing to implement the path mapping solution. However, I’m having trouble understanding the security benefit this would provide - if the interface gives read/write access to any arbitrary path on the system, the security model seems identical to classic confinement, just with added complexity requiring every application to implement snap-specific code for prefixing paths.
As for Firefox or any desktop application for that matter, I believe there is a fundamental difference from a CLI tool that operates directly in the user’s current working directory in a shell as part of system administration workflows.
Given the current state, would the “cloud management” category be applicable for SX’s server administration use case?
The mentioned existing system-backup interface that james describes only gives readonly access …
Does it manage containers or kubernetes workloads ? It would just be cheating to force it into such a category, we should have a “file server” category if it makes sense and it would fit in there (but an architect would have to add it to the process doc), lacking that the process is that an architect approves the exception…
Giving you classic means we permit you full root access to all users devices which simply needs to be handled extremely cautious …
Another point many people do not understand is that classic really requires a lot more work and testing when packaging, your snap must be installable and run on all possible distros snapd can run on, making 100% sure nothing leaks into your environment or outside of it. I.e. all your binaries need to be built in a way they can not accidentally use any libs from the host or inject any into the hosts environment, your snap must be packaged in a way it can run and behaves the very same on gentoo as well as on fedora, arch or debian…
Thank you for the insight on security implications and cross-distro requirements, ogra.
Regarding the interface - I was referring to James’s hypothetical new read/write interface idea, not the existing read-only system-backup interface.
As for the classic confinement technical requirements: This is a .NET application packaged using dotnet publish --self-contained, which means I’m relying on Microsoft’s implementation of self-contained deployment to work consistently across all Linux platforms. The same applies to library isolation and preventing host environment injection - that’s handled by the .NET runtime’s packaging system.
The implementation itself is quite minimal - a basic TCP client from the .NET framework that only listens on localhost. The source code is small and manageable to vet (~2k lines of C# code total).
Regarding categorization: While one could technically argue that SX can be used to manage container configuration files and similar server resources, I appreciate your point about the “file server” category being more appropriate. I’m happy to wait for an architect to either grant an exception or consider creating that category.
I understand the high bar for classic confinement and appreciate the thorough review process - this is the primary reason I want my project on snap: the trustworthiness of a built-in command to install the tool.
I understand that strict confinement is generally preferred over classic.