a parent item of an exclusivly locked item can be locked exclusivly again

[individual-it]

Steps to reproduce

1. have a file structure like: /PARENT/CHILD/child.txt
2. lock /PARENT/CHILD exclusively and depth infinity
3. lock /PARENT exclusively and depth infinity
4. propfind on /PARENT/CHILD/child.txt

Expected behaviour

second lock should fail
propfind should only report 1 lock

Actual behaviour

second lock works
propfind reports 2 exclusive locks

<?xml version="1.0"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:oc="http://owncloud.org/ns">
  <d:response>
    <d:href>/owncloud-core/remote.php/webdav/PARENT/CHILD/child.txt</d:href>
    <d:propstat>
      <d:prop>
        <d:lockdiscovery>
          <d:activelock>
            <d:lockscope>
              <d:exclusive/>
            </d:lockscope>
            <d:locktype>
              <d:write/>
            </d:locktype>
            <d:lockroot>
              <d:href>/owncloud-core/remote.php/webdav/PARENT</d:href>
            </d:lockroot>
            <d:depth>infinity</d:depth>
            <d:timeout>Second-1793</d:timeout>
            <d:locktoken>
              <d:href>opaquelocktoken:06e8c6ff-8db0-43ac-bf1c-eaa1137aaab3</d:href>
            </d:locktoken>
            <d:owner>uu1</d:owner>
          </d:activelock>
          <d:activelock>
            <d:lockscope>
              <d:exclusive/>
            </d:lockscope>
            <d:locktype>
              <d:write/>
            </d:locktype>
            <d:lockroot>
              <d:href>/owncloud-core/remote.php/webdav/PARENT/CHILD</d:href>
            </d:lockroot>
            <d:depth>infinity</d:depth>
            <d:timeout>Second-1774</d:timeout>
            <d:locktoken>
              <d:href>opaquelocktoken:10d8aa19-544b-43b1-a019-c23240e38389</d:href>
            </d:locktoken>
            <d:owner>uu1</d:owner>
          </d:activelock>
        </d:lockdiscovery>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
</d:multistatus>

[ownclouders]

GitMate.io thinks possibly related issues are #34329 (trying to unlock an item with the lock of a parent item does return HTTP code 204), #24737 (File Locked), #26838 (File locking), #17181 (Properly lock share owner parent folders), and #34225 (Parent share link path leaked through lock info).

[PVince81]

it seems Sabre doesn't query the child locks: https://github.com/sabre-io/dav/blob/master/lib/DAV/Locks/Plugin.php#L171

to get the child locks it should pass true as second parameter and it would get them.

not sure if this is a bug or whether the FileLocksBackend is supposed to implement those additional checks in its lock() method...

[PVince81]

I grepped the Sabre code and it seems the inclusion of children in getLocks() is only used when checking if an HTTP method is allowed, like "MOVE" https://github.com/sabre-io/dav/blob/master/lib/DAV/Locks/Plugin.php#L433 and also in the "unbind" event to clear locks of all node children after deletion.

[PVince81]

raised upstream sabre-io/dav#1133

[PVince81]

will be mentioned as known issue in owncloud/docs#574 as fixing this will take a lot more work, including upstream releases.