GFile operations on SFTP servers without requiring to mount the remote

I’m creating a backup program that uses SFTP server. Although the heavy lifting is done with RSYNC, there are several operations that I still need to do, like listing the available backups, or deleting old ones. Unfortunately, when I use GFile for that, it seems to require always to mount the remote unit (thus, it being available at /run/media/XXXX). This is not a good idea because it can result in a bugged or malicious program deleting the files.

Is there a way of avoiding that mount operation? If it is possible only for some operations, which ones are those?

I would not recommend using GFile for this: GFile is an abstraction that works best for enumerating and operating on files—basically, the functionality necessary to implement a file browser.

That’s not really going to matter, though: if the user is running a malicious (or a bugged) application, having your FTP server mounted under the runtime directory is going to be the least of the user’s problems.

I would not recommend using GFile for this: GFile is an abstraction that works best for enumerating and operating on files—basically, the functionality necessary to implement a file browser.

Yes, that’s basically what I’m doing with it: enumerating the contents of the folder with backups to know which backups are there (one folder per backup, with the date/time of the backup as the folder name, and using hard links for duplicated files), and delete old ones. The backups process is done with RSync, so that isn’t being done with GFile. Also, another thing that I do is the restoring interface, which is basically a file browser that allows to navigate through the backups and each file/folder in the backups, and restore only what you need.

Also, I know that there are bigger problems in the case of a buggy or malicious program running. My point is that I want to protect the backups for the specific case of ransomware: if the backups are exposed mounted in the filesystem, they can be encrypted too…