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!

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.

9

Thank you for the clarification, @Lin-Buo-Ren I apologize for the incorrect assumption about FileZilla.

This is actually very helpful — if FileZilla works with strict confinement, I’d love to understand how you solved the filesystem access problem.

Could you share:

  1. Which plugs/interfaces does FileZilla use to access directories outside

    $HOME

    ?

  2. Is there a specific portal or user-consent mechanism that allows broader access?

  3. Any documentation or examples I could follow to implement the same approach in AeroFTP?

I’m genuinely interested in making strict confinement work if there’s a viable path.

Thanks!

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: