-
-
Notifications
You must be signed in to change notification settings - Fork 4
Description
Description
When using ScpFs exists method, certain characters appearing in the path will result in the method failing for various reasons, even if the path does exist and is valid.
The following examples are to show the Linux commands that ScpFs is running under the hood.
Example 1, using a $. test -e "./this is a $m test.txt"; echo $?
Even if the file exists this will fail since the $ is not escaped. It fails with the error The system cannot find the file specified. (os error 2). create has no issue with these characters, but I suspect methods that call exists and fail on a true assertion may have undesired behaviour such as create_dir.
Example 2, using a ` . test -e "./this is you`re test.txt"; echo $?
This example will cause the check to fail with the error below since it is not escaped and therefore missing a closing `, I believe it may be possible for a malicious path to run code injection here. I haven't tested any of the other ScpFs methods to determine if they do or do not handle the ` case.
could not stat file (protocol error (Failed to get command exit code))
Caused by:
could not stat file
Steps to reproduce
- Set up a ScpFs connection to a remote server.
- Have ScpFs object run the
existsmethod with either of the two examples posted above - Create the files listed above on the remote_server
- Run step 2 again, and confirm that even though the files exist as expected, the
existsmethod fails
Expected behaviour
All supported Linux path characters should work when using RemoteFs and if the examples are provided, they should correctly identify if the file exists or not.
Environment
- OS: Windows 11
- Architecture: x86_64
- Rust version: 1.83.0
- remotefs version: 0.3.1
- Protocol used: SCP
- Remote server version and name: NixOs 24.11
Additional information
I am not sure if the expectation is for the user code to handle these cases, but I didn't see any documentation regarding these cases so I figured it would be best to raise this as an issue and let the maintainers decide how it should be handled.