https://webdav.mediencenter.t-online.de returns invalid response code.
e.g.
{"reqId":"f9a1c394b98108e4e5ca62bf47829c64","remoteAddr":"81.189.45.224","app":"PHP","message":"Undefined offset: 2 at \/var\/www\/owncloud\/3rdparty\/sabre\/dav\/lib\/Sabre\/DAV\/Client.php#569","level":3,"time":"2015-03-25T18:25:48+00:00","method":"GET","url":"\/index.php\/apps\/files\/ajax\/getstoragestats.php?dir=External%2FT-Cloud%2FTests"}
e.g.
{"reqId":"3407d66672b3cef206b0af883e49bff4","remoteAddr":"46.74.125.245","app":"PHP","message":"Undefined index: {DAV:}getlastmodified at \/var\/www\/owncloud\/lib\/private\/files\/storage\/dav.php#563","level":3,"time":"2015-03-25T16:33:21+00:00"}
Despite it's PHPDoc the function might return `null` which was not properly catched and thus in some situations the share was resolved to the sharing users root directory.
To test this perform the following steps:
* Share file in owncloud 7 (7.0.4.2)
* Delete the parent folder of the shared file
* The share stays is in the DB and the share via the sharelink is inaccessible. (which is good)
* Upgrade to owncloud 8 (8.0.2) (This step is crucial. The bug is not reproduceable without upgrading from 7 to 8. It seems like the old tokens are handled different than the newer ones)
* Optional Step: Logout, Reset Browser Session, etc.
* Access the share via the old share url: almost empty page, but there is a dowload button which adds a "/download" to the URL.
* Upon clicking, a download.zip is downloaded which contains EVERYTHING from the owncloud directory (of the user who shared the file)
* No exception is thrown and no error is logged.
This will add a check whether the share is a valid one and also adds unit tests to prevent further regressions in the future. Needs to be backported to ownCloud 8.
Adding a proper clean-up of the orphaned shares is out-of-scope and would probably require some kind of FK or so.
Fixes https://github.com/owncloud/core/issues/15097
In the past it seems the update permission was needed to be able to
rename shared mounts, but it doesn't seem to be the case any more.
Removing the "update" permission that used to be added automatically
fixes the read-only permission check when trying to overwrite a
read-only file over WebDAV.