Closed eikek closed 5 years ago
hey - thanks for the report! I did this on purpose for security, so we know that pointing gossa to a folder, its execution would always be contained only to that folder and nowhere else.
the code doing so is here, it's joining the path, resolving it and then checking it still starts with the path you initially provided, so it would basically error away any kind symlink. You can probably manually comment out these lines, and run this if you need symlink support, but I haven't tested :)
Thanks for your reply! I can see the security problem, of course. But since it works when the symlink is a direct child of root
and otherwise the files are listed, I thought it is expected to work :-)
IMHO this specific security problem is no so important :-), because one can argue that it is the server side, which the person who installs gossa controls anyways. It is of course much more important, that the client cannot browse outside of the root
(with ../../../etc/passwd
or so).
I agree - #26 assesses this, it's behind a symlinks
CLI flag.
Feel free to have a look and try out :+1:
Hello,
my directory served by gossa looks like this:
So
test/tmp
is a symlink to/tmp
. Then I run gossa via:I can change into the
test
directory and then intotmp
and I'll see all the files. But when I click a file, it is not found. The reason is that it is looked up using the wrong path. Here is the log output:The last line shows that it misses the
tmp
part of the path. It looks the file up intest
instead. It works iftmp
is a normal directory, but iftmp
is a symlink it doesn't work. Also, if the symlink is a direct child of the root dir, it works, too.