xvol allows symlinks to escape the root

[seanmcveigh]

not sure if this is design intent or not, but I am able to escape from a volume root via symlinks...

I created a symlink in ~/test pointing to ../../../backup.
cd ~/test && ln -s ../../../backup backup

Then I started copyparty in ~/test using the following args:
copyparty -a foo:bar -v .::r:rwdm,foo:c,xvol

I am able to see the backup folder in my root and can follow the symlink and escape from the volume root. This is also reproducible with absolute symlinks like:
cd ~/test && ln -s /backup backup

version info:
running on ubuntu 18.04 LTS
copyparty v1.6.15 "cors k" (2023-04-26)
CPython v3.6.9 on Linux64 [GCC 8.4.0]
sqlite v3.22.0*1 | jinja2 v3.0.3 | pyftpd v(None)

[seanmcveigh]

as an addendum, xdev does not stop me from following a link to another device as well:
cd ~/test && ln -s /mnt/another/disk disk

I can see disk/ in my root, and can navigate into it.

[9001]

Good call -- both xvol and xdev currently only affect the filesystem indexer, which I notice is not very well documented. Sorry!

The reason they don't apply at runtime was mostly due to performance, but in hindsight it would be worth it in exchange for much more intuitive behavior. So that will probably change :>

However, symlinks by default being permitted to leave volumes is intentional, as a common usecase is people sharing folders in their home by symlinking them from /var/www or similar. Maybe it would make sense to have an allowlist/denylist of filesystem locations to permit access to... I'll think about it for a bit 👍

[9001]

Alright -- version 1.7.0 is up, hopefully fixing both this and #23 -- let me know if you run into any issues :>

Ended up not adding the allowlist/denylist after all; those usecases can probably be covered well enough with volumes as it is.

[seanmcveigh]

thanks for the quick attention :)