search

linuxmint / warpinator

Share files across the LAN
GNU General Public License v3.0
1.21k stars 81 forks source link

Failure when download path is symlink #188

Open WhosyVox opened 1 year ago

WhosyVox commented 1 year ago

Distribution

Mint 21.2

Package version

1.6.4+victoria

Frequency

Always

Bug description

Warpinator cannot accept incoming files if the download location is a symbolic link. ('Location for received files' within the app)

The exact error returned is:

Resolved path is not a valid child of the save folder: [symlink path]/file -> [real path]/file

This was working in some prior release (within the last few weeks I expect, given when I last used the tool.

Steps to reproduce

  1. Create a symbolic link to some valid directory you have read/write access to
  2. Point Warpinator's download location to the symbolic link path
  3. Attempt to send a file from another device to that instance of Warpinator

Expected behavior

The file should be downloaded successfully.

Additional information

I can see some argument as to whether following symbolic links would be dangerous, as it could allow an attack that leaks file contents out of the chosen download location.

In this case an exception should be made only for the Download directory itself, and not for any nested paths.

Alternatively if this is expected behaviour, there should be a warning or error provided when selecting a symbolic link as a download target.

WhosyVox commented 1 year ago

I'm thinking this might be related to the 9aae768 commit, but I could be wrong.

mtwebster commented 1 year ago

What location is the link pointing to?

Forage commented 1 year ago

I can confirm this issue occurring with:

A path like /mnt/Data/Downloads/Warpinator in Flatseal and Warpinator works. A symlink from /home/user/Downloads to /mnt/Data/Downloads followed by /home/user/Downloads/Warpinator as path in Flatseal and Warpinator does not work.

Sending a file from Android to Ubuntu gets cancelled right away.

WhosyVox commented 1 year ago

What location is the link pointing to?

The link was originally ~/temp -> /mnt/temp, but, in testing, even ~/temp -> ~/temp2 resulted in the same error.

It appears that at some stage the application checks that the received files are kept within the configured download directory, but compares the path of the symlink against the path the symlink points to.