filestash icon indicating copy to clipboard operation
filestash copied to clipboard

[bug] Symlinked folders are displayed but not accessible

Open Apollo3zehn opened this issue 2 years ago • 9 comments

Description of the bug

I created a folder for the "local" plugin which consists of symlinks only. These symlinks point to the actual folders I want to expose via filestash.

When I connect via the GUI the symlink folders are shown but I cannot open them. Instead I get "no such file or directory".

Step by step instructions to reproduce the bug

See above.

Can you replicate that error from the demo?

No.

Observed behavior

See above.

Expected behavior

I expect the symlinks to be followed properly or not displayed at all (not preferred).

I guess the error comes from this line:

https://github.com/mickael-kerjean/filestash/blob/9a1045cb02948a60c438343b552aede1fc915756/server/common/files_linux.go#L13

Is there a specific reason for the O_NOFOLLOW flag?

Thanks!

Apollo3zehn avatar Dec 23 '22 21:12 Apollo3zehn

Ah, could it be that symlinks do not work properly in a docker container because the path they point to is not necessarily accessible from within that container?

Apollo3zehn avatar Dec 24 '22 23:12 Apollo3zehn

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] avatar Jun 18 '23 14:06 stale[bot]

I have the same situation, where I am creating a folder for each of my potential users and then symlink-ing the folders they are allowed to access into those folders, then using the local backend. @mickael-kerjean I'm assuming you added all of the Safe wrappers in files_all for security reasons, can you describe what the risks are and what could happen if I create an "unsafe" local backend that uses the os. calls directly?

SteffeyDev avatar Jan 23 '24 04:01 SteffeyDev

for security reasons, can you describe what the risks are and what could happen if I create an "unsafe" local backend that uses the os. calls directly?

Supporting symlinks would be a security hazard as it would be very bad news if someone was able to jump to your /etc/passwd or onto the filestash config and make changes, essentially owning your entire instance. Supporting symlink would assume trust with your users which Filestash can't assume by default. Supporting simlink would be very simple though, you just need to copy the base plugin and remove all the extra code that is there to prevent that exact use case

mickael-kerjean avatar Jan 23 '24 06:01 mickael-kerjean

Thanks for the quick reply. Yes, I was able to modify the local plugin to be unsafe and everything worked as expected. The risks you mentioned seemed to involve the user creating their own symbolic links; is there anything in filestash that would allow users to create new symbolic links? I tried creating a symlink locally so I could upload it, but it was treated as a folder so it just uploaded the contents of what the symlink pointed to, instead of the symlink itself. Or is the primary concern that they could exploit a different method to have the symbolic link created, and then use filestash to follow it?

SteffeyDev avatar Jan 23 '24 13:01 SteffeyDev

is there anything in filestash that would allow users to create new symbolic links?

Not that I know of but I wouldn't bet my life on nobody finding a sneaky way around it in which case it would be considered a very bad security issue that need urgent fixing.

Or is the primary concern that they could exploit a different method to have the symbolic link created, and then use filestash to follow it?

Precisely yes, once symlinks are open, all odds are off as someone could potentially replace the Filestash binary with a trojan version that exfiltrate everything ... That's why I was initially against creating the local backend plugin as that risk can't be fully prevented but somehow most people still wanted that and didn't care so I had to find a way to strictly handle symlinks. That's the gist of it all

mickael-kerjean avatar Jan 23 '24 14:01 mickael-kerjean

Thanks for the quick reply. Yes, I was able to modify the local plugin to be unsafe and everything worked as expected. The risks you mentioned seemed to involve the user creating their own symbolic links; is there anything in filestash that would allow users to create new symbolic links? I tried creating a symlink locally so I could upload it, but it was treated as a folder so it just uploaded the contents of what the symlink pointed to, instead of the symlink itself. Or is the primary concern that they could exploit a different method to have the symbolic link created, and then use filestash to follow it?

How did you modify the base plugin to allow following symlinks? I'm trying to do the same thing on an RO share.

hoggatt avatar Apr 19 '24 16:04 hoggatt

Here's my commit, which is on a branch in my fork: https://github.com/SteffeyDev/filestash/commit/f1cc2198da7daea6f5639a228c2666c07383070f

Looks like I left some debug print statements in there, which are unnecessary of course. This has been working very reliably for the past few months.

SteffeyDev avatar Apr 19 '24 17:04 SteffeyDev

Thanks so much! I appreciate it.

hoggatt avatar Apr 19 '24 17:04 hoggatt