[Feature request] Remote file systems (tab completion when moving torrents, fopen)

[rsekman]

In #85 the question of tab completion when interfacing with a remote transmission daemon was raised. It was ultimately dropped, but I do use stig to interact with transmission on a seedbox, so this would be useful for me.

@rndusr suggested

Or there could be a configurable command (ssh) that returns the directorytree on the server

I would suggest using rsync, like this:

~% rsync schwarzschild:/home/karl
drwx------          4,096 2021/10/26 19:34:07 karl

This way it is not necessary to send commands constructed as strings to the remote, which could pose a security risk. Instead we call something like

subprocess.run("rsync", "host:%s" % Pathlib.Path(...) )

We do need to handle some errors, at the very least ENOENT, EACCESS (but these are also present on local filesystems). We should also handle ETIMEDOUT and other connection errors.

Now, opening a new remote shell for each tab completion could incur a significant overhead cost, but it is possible to reuse an open SSH session, cf. https://unix.stackexchange.com/questions/50508/reusing-ssh-session-for-repeated-rsync-commands. We could open the ssh tunnel on startup (in a non-blocking thread, perhaps) and close it on exit.

Remote and local paths disagreeing is also relevant to #200. A solution is to allow a sort of "symlinking" or translation layer: configure that /var/transmission/downloads/ on the remote should be translated to /mount/nfs/seedbox on the local, say. This translation layer should be fairly simple to implement robustly with Pathlib. It could also be an alternative for the previous issue: a local path is just translated into a remote path before being sent to the daemon. This way the remote is completely abstracted; to the user it looks like moving files locally. On the other hand it creates more tight coupling.

I can't promise I have time to work on this in the very near future, but if the ideas sound good let me know and I'll get to them when I can.

[rndusr]

Thank you for sharing your research.

My plan was to add a configurable command that prints a list of files and directories. This makes things more flexible for exotic setups. The default command would be safe, and if an attacker can change it, it's game over anyway.

But I like your path translation layer idea better. Sounds a lot simpler to implement. It's not as flexible and you need to setup a remote file system, but many users may have that setup anyway.

But I have no idea how you would implement that at the moment. It's been too long since I've worked on stig.

[rsekman]

The default command would be safe, and if an attacker can change it, it's game over anyway.

I am less worried about malicious attacks for this reason, but rather bugs in stig making us accidentally send something silly like ls /var/transmission/; sudo rm -rf / to the server.

Sounds a lot simpler to implement. [...] But I have no idea how you would implement that at the moment.

I think it will be simple enough that it will be easier to let the code explain how. I'll submit a pull request.