Request for classic confinement for 'aeroftp'

store-requests classic-confinement
1 
/var/www/html

, system config directories, or mounted drives) which strict confinement prevents. Additionally, it provides an integrated SSH terminal for executing commands on remote servers, which fits the ‘terminal-emulators’ category for classic confinement. Existing interfaces like

home

or

removable-media

are insufficient for professional workflow requirements.

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.

2

Not a reviewer, however as one who frequently deploys network services we rarely need to have arbitrary filesystem access at the local end. Access to home and removable-media confinement interfaces are adequate for such use cases.

1 Like
3

For this use case, classic confinement is not necessary at all as strict confinement only confines the local end, not remote.

2 Likes
4

This request has been added to the queue for review by the @reviewers team.

5

I agree with @Lin-Buo-Ren, I think classic confinement is not appropriate in this case.

I’m removing this request from the review queue. Feel free to open a new request if you need any support making your snap work under strict confinement

Thanks!

1 Like
6

Hi, If you both believe classic confinement isn’t appropriate, who am I to say otherwise? I’ve encountered some issues, which is why I requested classic confinement.

I’ll now try to resubmit the strict confinement-compatible version, along with other fixes.

Thank you for your cooperation and interest.

A.

2 Likes
7

Hi @jslarraz , @Lin-Buo-Ren

Thank you for your previous feedback. I’ve taken the time to deeply analyze the technical constraints and user requirements of my application, and I’d like to respectfully reopen this discussion with additional context.

After reviewing the specifics of what strict confinement would mean for AeroFTP users, I’ve concluded that the limitations would severely impact the core functionality of the application. I’d appreciate your input on whether an exception could be made, or if there’s an alternative path I’m not aware of.

I’ll explain my reasoning in detail below.

Core Technical Requirement

The fundamental purpose of an FTP client is to transfer files between a remote server and **any local directory** chosen by the user.

With strict confinement (`home` + `removable-media` plugs), AeroFTP would only be able to access:

- `$HOME/*`

- `/media/*` and `/mnt/*`

This excludes critical paths that are standard in professional workflows:

| Path | Use Case | Accessible? |

| ------------------------- | ------------------------ | ----------- |

| `/var/www/html` | Web development | :cross_mark: No |

| `/opt/application` | Self-hosted apps | :cross_mark: No |

| `/srv/data` | Server data directories | :cross_mark: No |

| `/etc/nginx` | Configuration management | :cross_mark: No |

| `/var/lib/docker/volumes` | Docker deployments | :cross_mark: No |

These are not edge cases — they represent the **primary audience** for FTP clients.

Why `personal-files` Plug Doesn’t Solve This

The `personal-files` plug requires specifying exact paths at build time. This approach doesn’t work for an FTP client because:

1. **Every user has different directory structures** — we cannot predict where projects are stored

2. **Users need to navigate freely** — the destination folder is chosen at runtime, not predetermined

3. **Batch operations and synchronization** require persistent directory access, not one-time file selection

The `desktop` portal for file picking also doesn’t help because:

- FTP clients need to **remember** directories across sessions

- Users perform bulk operations on entire folder trees

- Sync features monitor directories continuously

Precedent - Other FTP Clients

FileZilla, the most popular FTP client, uses classic confinement on the Snap Store for the same reason:

https://snapcraft.io/filezilla

The pattern is established: file transfer applications that need arbitrary filesystem access use classic confinement. This isn’t a workaround — it’s the appropriate solution for this category of software.

Security Considerations

I understand the security rationale behind strict confinement. Here’s how AeroFTP addresses security despite needing classic:

1. **Open source**: Full code at GitHub - axpnet/aeroftp: ⚡ AeroFTP - Fast, Beautiful, Reliable FTP Client built with Tauri + React

2. **No background processes**: Only runs when explicitly opened

3. **No auto-execution**: Only reads/writes files the user explicitly selects

4. **Encrypted transfers**: Supports FTPS (TLS)

5. **Minimal scope**: Doesn’t require audio, bluetooth, or other unrelated permissions

The risk profile is identical to FileZilla and other file managers.

The Alternative Would Harm Users

If I publish AeroFTP under strict confinement, users would:

- Get a broken experience (can’t access `/var/www`, etc.)

- Leave negative reviews (“doesn’t work”)

- Uninstall the Snap

This damages both the user experience and the Snap ecosystem’s reputation.

If classic isn’t granted, my only ethical choice is to:

- Not publish on the Snap Store

- Direct users to AppImage / .deb instead

I would prefer to offer AeroFTP on Snap Store with proper functionality.

Request for Reconsideration

Based on the above, I respectfully request reconsideration of classic confinement for AeroFTP.

Key points:

- **FTP clients inherently require full filesystem access** — this is not optional

- **Precedent exists** — FileZilla has classic confinement

- **Security is addressed** — open source, no background services, encrypted protocols

If there are specific concerns or additional information you need, I’m happy to provide it.

Thank you for your time and consideration.

A.

8

For the record(I am the publisher of the referenced snap), this snap uses strict confinement.

10

Thank you @Lin-Buo-Ren for the clarification — and I appreciate you taking the time to respond!

I’ve just reviewed your FileZilla snap’s

snapcraft.yamland I see you’re using strict confinement with

home

removable-media

plugs. I apologize for the incorrect assumption in my earlier message.

This helps clarify the situation. I now understand that:

  • FileZilla snap users can only access

    $HOME

    and removable drives

  • Users who need access to

    /var/www

    ,

    /opt

    , etc. must use the non-Snap version

I have to be honest: this is a significant limitation for my use case. AeroFTP includes an AeroCloud sync feature that monitors and synchronizes directories in real-time — and many of my users work with web projects in

/var/www

or containerized setups in

/var/lib

That said, I understand the security rationale behind strict confinement, and I respect the decision.

My options are:

  1. Publish with strict confinement and clearly document the

    $HOME

    limitation

  2. Focus distribution on AppImage/deb for users who need full filesystem access

Before I decide — is there any interface or portal mechanism that could allow user-consented access to arbitrary paths at runtime? Or is

home

removable-media

truly the maximum available under strict?

Thanks again for your insight. Your work on the FileZilla snap is impressive! :raising_hands:

12

@jslarraz Sorry, I’m new here. I have 20 years of experience in other programming areas with custom CMS and CRMs. With AeroFTP, my goal is simply to contribute to the open source community and to older cyberpunk developers like myself who have always enjoyed free software.

Regarding the strict confinement limitations and the discussions we had above, having investigated and found publicly //github dot com /brlin-tw/filezilla-snap/issues/7 discussions on the matter, it’s definitely clear that my request was correct. Users are rightly complaining about the snap version of FileZilla! So I don’t understand the point of the discussion above.

The strange thing was that I was initially granted classic confinement, but later, after this discussion, it was erroneously revealed that it was possible to publish the app with strict confinement without the problems I had reported.

In short, it’s clearly an arbitrary choice, without any reasonable justification, to confine apps like AeroFTP or FileZilla to strict confinement, severely limiting the apps, making them almost unusable, as if they were just demos.

My small contribution, good luck! :saluting_face:

  • I have published—let’s call it—the “strict-snap-DEMO” version of AeroFTP

… while waiting to hear more about when I can publish the fully functional version with classic confinement :rocket:

14

Can you point to the conversation that granted you classic ? Getting classic confinement only happens as a manual process after a conversation like the one you are having here, so if this is true you must have had a former public discussion around this (which you should have pointed to in your initial post here)

In general classic is only granted to a very limited set of applications at all since they must fall into a valid category and fulfill a lot of prerequisites (verified publisher with direct upstream involvement, vibrant community, sustained security history etc)

You picked “terminal-emulators” as the category of your snap, note that FTP clients are not terminal emulators, that would be xterm, gnome-terminal etc. which your app is not, there is no category like “FTP clients” in the list of apps we could approve classic confinement for, please see:

1 Like
15

I also wonder what is the statement based on. I checked the store and there is no approved version of the snap using classic confinement. Only version using strict confinement passed automatic review (#2, #3 and #6)

1 Like
16

Before I decide — is there any interface or portal mechanism that could allow user-consented access to arbitrary paths at runtime? Or is home and removable-media truly the maximum available under strict?

As of today, the general answer I think is yes.

There is some effort in the direction to allow the user decide what permissions they want to grant in runtime, but I don’t know if your usecase is already covered and I think it only works on very recent ubuntu releases

1 Like
17

Dear Snap Friends @jslarraz, ogra , OK, maybe I was hallucinating when I thought I’d initially been approved for classic confinement. I admit I was confused during my various tests. Now everything is clearer: my app clearly needs classic confinement to be fully functional (just as FileZilla Snap would). There’s no point in explaining the reasons again; they’re obvious.

The real problem, reading other classic confinement requests, is simply that:

  1. The project appears to be very new, according to the upstream repository.

  2. According to the upstream repository (contributors, issues, PR, etc.), the project appears to have little to no community.

  3. There’s no evidence that the project currently has a sufficiently robust user base.

I can’t argue with these points, since AeroFTP was actually born just a few weeks ago in extraordinary times (from a hallucination and teamwork between me and multi-agents, haha).

But given the interest this chat has generated (even among the competitors, @Lin-Buo-Ren hahaha :smiling_face:), it’s likely that over time, if I keep the project updated, things could change.

My best wishes, it was a pleasure entering this world of developers, I’m always grateful and excited for my first app on Snapstore :tada:

ciao!

18

@axpnet

Some recommendations:

  • Improve communication to the users regarding the limitation of the snap distribution via Inform users with custom dialogs , this mitigates the concern of reputation damage when user found they can’t achieve certain goals using this type of the distribution.
  • You can package and distribute snaps in classic confinement via external channels like GitHub releases. Just note that in this case the snap can’t be automatically updated so you need to implement update checking logic to tell the user whenever a new release of the application is available.
  • Investigate the possibility of allowing arbitrary file access via the XDG Desktop Portal mechanism, the difficulty of make use of this mechanism depends on the tech stack of your app.
  • You can also consider distributing you application via Flatpak, which do allow the users to manually override access confinement to certain paths.
  • Verify your facts before responding; unsubstantiated claims will only undermine your position.
1 Like
19

@Lin-Buo-Ren Thanks a lot for the detailed and practical recommendations! I really appreciate the time you took to share your experience.

I’m already waiting for the Flathub review for Flatpak (which should handle arbitrary file access much better via xdg-desktop-portal and manual overrides), so that aligns perfectly with your suggestion.

For the strict Snap version, I’ll definitely look into improving user communication with custom dialogs to explain the limitations clearly – great tip to mitigate potential reputation issues.

On the XDG Desktop Portal side, I’m investigating integration in my Rust + Tauri stack (maybe via the ashpd crate, which seems promising for Rust bindings). Do you have any quick tips or examples on using ashpd for file chooser portals in a Tauri app? It would be super helpful!

Also, the idea of external classic snaps via GitHub releases with manual update checks is interesting – I’ll consider that as a fallback for power users.

Thanks again for the constructive input – it’s really valuable coming from someone with your background!

20

Hi,

Thanks for the recommendations. I’ve addressed them as follows:

  1. User communication: Added a first-launch dialog explaining strict confinement limitations and accessible locations.

  2. XDG Desktop Portal: Already integrated via tauri-plugin-dialog - the system file picker grants temporary access to files outside the sandbox.

  3. Alternative distributions: Users are informed about .deb and Flatpak options in the dialog.

I’m proceeding with strict confinement as published. Thanks for the guidance!

3 Likes