Open rsekman opened 2 years ago
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.
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.
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
I would suggest using
rsync
, like this: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
We do need to handle some errors, at the very least
ENOENT
,EACCESS
(but these are also present on local filesystems). We should also handleETIMEDOUT
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 withPathlib
. 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.