search

cs3org / reva

WebDAV/gRPC/HTTP high performance server to link high level clients to storage backends
https://reva.link
Apache License 2.0
167 stars 113 forks source link

PROPFIND on OCM share target returns incorrect results #3810

Closed redblom closed 1 year ago

redblom commented 1 year ago

To reproduce follow the OCM share tutorial (https://reva.link/docs/tutorials/share-tutorial/). After a share has been created do a curl PROPFIND on its target:

(taken from the tutorial)

curl -X PROPFIND http://localhost:19001/remote.php/dav/ocm/eSWNjTWjorFmZEGQNZVyrU3TyxdWEr1D

This will return:

...
<d:response><d:href>/remote.php/dav/ocm/eSWNjTWjorFmZEGQNZVyrU3TyxdWEr1D/home/my-folder/</d:href><d:propstat>
...

The response hrefs contain the 'home path' of the share which should not be the case. An additional PROPFIND on those results will fail with a not found error. This is because reva will stat {user}/home/my-folder/home/my-folder which does not exist. When there is another folder inside the share, eg. home/my-folder/another-folder and you PROPFIND as follows:

curl -X PROPFIND http://localhost:19001/remote.php/dav/ocm/eSWNjTWjorFmZEGQNZVyrU3TyxdWEr1D/another-folder

you will get results, albeit again including the share's 'home path':

...
<d:response><d:href>/remote.php/dav/ocm/eSWNjTWjorFmZEGQNZVyrU3TyxdWEr1D/home/my-folder/another-folder</d:href><d:propstat>
...

Unfortunately the fix does not seem to be a case of simply removing the share's 'home path' from the results because that does not work for files. Eg. a file in /home/my-folder can not be PROPFINDed by:

curl -X PROPFIND http://localhost:19001/remote.php/dav/ocm/eSWNjTWjorFmZEGQNZVyrU3TyxdWEr1D/test-01.txt

This also fails with a not found error.

gmgigi96 commented 1 year ago

Indeed I'm just noticing that even in the doc the URL returned by the PROPFIND is wrong.

I was debugging the code, and I found out that the issue is not in the OCM part itself, but in the localhome storage driver. And the issue is the following: given a resource-id, the path returned statting is different depending on the user doing the operation. For example, for Einstein it gets resolved to /home/my-folder while for Marie to /home/einstein/my-folder, and of course this is a problem as at OCM layer we are heavily relying on the path to build the OCM path. Now, I don't know which was the original design of the /home (maybe @labkode can help on this), but I would expect that /home should just be a reference to a real path, so that no matter which is the user, it gets resolved to the same path for every user.

I think for now a workaround could be to just not share from the /home folder, but for this we need to add an other storage driver in the config and clearly state on the doc to not share from /home.

redblom commented 1 year ago

@gmgigi96 FYI, the issue also occurs when home_provider = /. But I'm not sure if that is what you mean by 'we need to add an other storage driver in the config'.