"download directory path is not absolute" is inconsistent

[cfpp2p]

rpcimpl.c sessionSet() calls tr_sys_path_is_relative (download_dir) to validate the download directory path before calling session.c tr_sessionSetDownloadDir() However the download directory path is not validated for any other calls to session.c tr_sessionSetDownloadDir()

The same holds true: for rpcimpl.c torrentAdd() calling tr_sys_path_is_relative (download_dir) to validate the download directory path before calling torrent-ctor.c tr_ctorSetDownloadDir() However the download directory path is not validated for any other calls to torrent-ctor.c tr_ctorSetDownloadDir()

[vensko]

Just bring back relative path support and stop fixing what's not broken.

[mikedld]

Initial goal was to reject relative paths coming through RPC and it has been reached. Protecting from relative paths coming through C API is of less priority but is nevertheless planned as well. Thanks for bringing it up @cfpp2p.

[Kerdek]

at what point does it become individual programs' responsibilities to filter filesystem access? this is what we call the shotgun approach to security. i can't use transmission right now because of this

[mikedld]

Sure you can, just specify an absolute path.

It's not that much about security but the fact that it's not clear what those relative paths should be relative to. It doesn't make sense to make them relative to the configuration directory IMHO (because Transmission relies on a particular structure of that directory and putting some new files there or accidentaly overwriting/removing files put there by Transmission can lead to issues), and there's no any other more or less fixed directory both Transmission and its users know about. Previous behavior was that the path was relative to Transmission's current working directory which doesn't make a lot of sense either because that directory is private to the process and shouldn't be relied upon (including because it can change during process lifetime, even if you know what it was in the beginning).

If there's a particular use case that you think is broken, let's discuss, sans the drama.

[vensko]

I have a particular case - self-contained, fully portable Transmission instances. Relative paths allow to store Transmission and downloads together, move, backup, and launch from any location without fixing paths. 2.84 is the last version, when this was possible.

[Kerdek]

There is no drama. I should only need to point out that the textbook says not to do this. I should not need to re-hash the textbook use-cases which are broken when programs adopt concerns which are not rightfully theirs.

On Wed, Jul 20, 2022 at 5:28 PM Mike Gelfand @.***> wrote:

Sure you can, just specify an absolute path.

It's not that much about security but the fact that it's not clear what those relative paths should be relative to. It doesn't make sense to make them relative to the configuration directory IMHO (because Transmission relies on a particular structure of that directory and putting some new files there or accidentaly overwriting/removing files put there by Transmission can lead to issues), and there's no any other more or less fixed directory both Transmission and its users know about. Previous behavior was that the path was relative to Transmission's current working directory which doesn't make a lot of sense either because that directory is private to the process and shouldn't be relied upon (including because it can change during process lifetime, even if you know what it was in the beginning).

If there's a particular use case that you think is broken, let's discuss, sans the drama.

— Reply to this email directly, view it on GitHub https://github.com/transmission/transmission/issues/173#issuecomment-1190775630, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACDEXTCMEYHD3CQOIOZ7THDVVBVQPANCNFSM4C7ERBXQ . You are receiving this because you commented.Message ID: @.***>

--

-Theodoric

[ckerr]

There is no drama. I should only need to point out that the textbook says not to do this. I should not need to re-hash the textbook use-cases which are broken when programs adopt concerns which are not rightfully theirs.

Thank you for your kind thoughts.

[mikedld]

I have a particular case - self-contained, fully portable Transmission instances. Relative paths allow to store Transmission and downloads together, move, backup, and launch from any location without fixing paths. 2.84 is the last version, when this was possible.

It sounds like you want paths to be relative to the executable location. That's not really how it worked before, even if it looked like it, so it would require explicit support of some sort. Then again, you can just have a batch/shell script to run Transmission intead of doing so directly, and that script would then be responsible for passing needed absolute directories (calculated relative to executable location or anything else you desire) via --config-dir, --download-dir, --incomplete-dir, etc.

There is no drama. I should only need to point out that the textbook says not to do this. I should not need to re-hash the textbook use-cases which are broken when programs adopt concerns which are not rightfully theirs.

I'm still not sure what you're suggesting. You said you can't use it but didn't provide a use-case — not the first time, not the second time. We can't help you if you don't want to tell us what's broken, and I personally don't want to rush into a fix unless I know for sure it's not a XY problem.

Bringing back old behavior seems like a bad idea (and bad design) — you won't know what the directory is relative to. It's one thing to accept relative paths via command-line interface working with local services, when users understand what current working directory is and what the path is relative to, and rightfully expect it to be handled properly. It's another thing to put relative paths into a configuration file or transfer them via network to be interpreted on another machine, where information on base directory is simply non-existent. This includes transmission-remote: although it is a CLI tool, and it can theoretically accept relative paths and transform them to absolute internally, this would only work with a local session; otherwise it would make no sense because a) as mentioned before, remote session has no notion of publicly documented and reliable base directory to transform relative paths to absolute on its own (and you don't want your downloaded files written to a random place), and b) transforming relative paths to absolute on client's side would mean that those paths will be specific to client's machine and may well be invalid on the remote machine it's being sent to (even more so if remote machine is using a different OS).

[vensko]

I'm aware how it works in 2.84, it uses the working directory, which is as easy to manipulate as command line parameters. A command line parameter setting the base path for relative paths would be a good solution, too.

[mikedld]

@vensko, I've commented in https://github.com/transmission/transmission/issues/6045#issuecomment-1745471844 with a potential implementation option. Not yet sure how convenient it'll be or if other devs would agree, but it'll solve your use-case as well. Would appreciate your thoughts, or maybe you have another idea for us to consider.