Classic confinement for sFTP Client


#1

Hello,

We’d like to request Classic confinement for sFTP Client (www.sftpapp.com).

sFTP Client is a File Transfer application for FTP, SFTP, FTPS and Cloud Services, including an SSH Terminal, Port Forwarding and more…

We’ve had several reports from our users unable to access several different parts of their filesystem, for example:

  • Network Mounts
  • ~/.ssh (to select key files for server login)
  • /opt/ (for lampp or other local developer tools)

Our users have their projects in many different areas of their filesystem and the above is some mentioned.

I believe from reading your documentation we’d need the Classic confinement to achieve this, and anyone who’s previously installed would need to run snap refresh sftpclient --classic? or running snap remove sftpclient followed by snap install sftpclient --classic, if we’re able to get this confinement we can update our documentation and app for anyone needing to do this.

Thanks in advance and we’re looking forward to hearing from you, if you require any more info from us or have any questions please let us know.

Best regards,
Danny
sFTP App Ltd


#2

I’m not familiar enough with network mounts to know what would be necessary/reasonable to make access to these work with strict confinement. What paths are these at?

For this, there is the ssh-keys and ssh-public-keys interfaces which would allow access to these files.

I’m not sure about this one, but perhaps we could have an interface for mounting /opt from the host into the snap’s mount namespace like we do for /etc? Looking at it, we don’t currently allow access through any interface to /opt, and there is nothing in /opt in the core or core18 snap. @jdstrand what do you think?


#3

Hello @ijohnson,

Thanks for the quick response here!

The network mounts is nothing specific (user specified), when a user specifies a local directory to use within our app to perform (local - remote / remote - local) transfers they are presented with the filesystem directory selection, this does not seem to allow our users to select a network path for projects or other data users need to transfer. We’re not the typical FTP/FTPS/SFTP file transfer client, we also provide connections to cloud services too (i.e. Amazon S3, Dropbox, Backblaze B2, Google Cloud Storage, etc etc).

I suppose the use of ssh-keys / ssh-public-keys interfaces would resolve this specific issue, although i’m sure wont be necessary if we had the Classic confinement.

The /opt directory is one example of many root based directories (or non home based directories), another example would /backup to backup data to their remote servers / services, to find other examples i’d have to go through many support tickets / emails to find these, although my point is many of our users have reported issues with accessing non-home based directories.

Really hoping we can get these issues resolved for our users soon.

Best regards,
Danny
sFTP App Ltd


#4

It would be useful if you could compile a list of commonly requested directories, because from my experience /home or /media is usually enough for most use cases and so if there are common use cases for other directories we would like to understand them so that eventually we could attempt to craft strict interfaces allowing such accesses.

Additionally, there is an open PR (see https://github.com/snapcore/snapd/pull/6436) which hopefully will eventually add a system-backup interface which would allow read-only access to any directory on the system (other than /dev, /sys, and /proc) which sounds like it would partially solve your use case.

Not sure what to do about the network mounts access, sounds like it could be a GUI bug with the file chooser not searching all paths properly or it could be something else entirely.