Parent share link path leaked through lock info

[PVince81]

Steps

1. Create a folder "/abc/test/a"
2. Lock "/abc" with exclusive lock
3. Share "/abc/test" with link
4. Query lock info with PROPFIND on public webdav from link:

curl -u $linktoken:\
  -X PROPFIND \
  --data-binary "@propfind.xml" \
  -H "Content-Type: text/xml" \
'http://localhost/owncloud/public.php/webdav/x' | xmllint --format -

Expected result

Lock root is always "public.php/webdav/"

Actual result

Lock root contains the parent folder name: "public.php/webdav/abc" which leaks the parent folder names and itself isn't even a valid folder since there is no "abc" in "test".

Versions

Observed on master while fixing #34224

Making that p2 as this would introduce a security issue about information disclosure.

@DeepDiver1975 @davitol FYI

[PVince81]

The used storage is just Home, so no URL rewriting to be done on storage layer.

Idea to explore: make the FileLocksBackend aware of whether we are on a public endpoint or not.
We might even need to expose the original share info there to be able to verify whether the lock URL is actually inside the share or outside. If outside, we set the absoluteDavUri to "/".

[PVince81]

The $view is only available inside the viewCallback() which initializes the ObjectTree->init().

But the lock backend is receiving a non-initialized tree object. We currently seem to assume that the tree is properly initialized once the locks are queried.

For public link shares, the attached $view is the one of the share owner and its path is set to the share root. We could read it using $view->getFakeRoot() or $view->getRelativePath() to find out the subpath relative to the public webdav root.

[PVince81]

PR here: #34229