send PUT requests to another user's webDav endpoints as normal user

[SwikritiT]

Describe the bug

Sending PUT request to another users' WebDav endpoints as normal user gives different status code for oc10 and ocis

Steps to reproduce

Steps to reproduce the behavior:

1. Create user Alice and Brian
2. As Alice create a folder PARENT
3. As Alice create file /PARENT/parent.txt and textfile1.txt
4. Send PUT request to endpoint /remote.php/dav/files/Alice/textfile1.txt as user Brian with body doesnotmatter
5. Then the HTTP status code should be "403". This is the same for both oc10 and ocis
6. Now again sent PUT request to endpoint /remote.php/dav/files/Alice/PARENT/parent.txt as user Brian with body doesnotmatter
7. HTTP status code is 403 for ocis and 409 for oc10.

Expected behavior

I don't know what the expected behaviour is for this one probably ocis one? I'm putting oc10's behaviour here

PUT /core/remote.php/dav/files/Alice/PARENT/parent.txt HTTP/1.1
Host: 172.17.0.1
User-Agent: GuzzleHttp/7
Authorization: basic QnJpYW46MTIzNA==
OCS-APIREQUEST: true
Content-Length: 13
PUT /core/remote.php/dav/files/Alice/PARENT/parent.txt HTTP/1.1
Host: 172.17.0.1
User-Agent: GuzzleHttp/7
Authorization: basic QnJpYW46MTIzNA==
OCS-APIREQUEST: true
Content-Length: 13

doesnotmatter

HTTP/1.1 409 Conflict
Date: Fri, 12 Nov 2021 06:12:22 GMT
Server: Apache/2.4.41 (Ubuntu)
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
X-Robots-Tag: none
X-Frame-Options: SAMEORIGIN
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Set-Cookie: oc5soe2gvutv=187de14cdgm8rp3rtbiuljto5c; path=/core; HttpOnly; SameSite=Strict
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Set-Cookie: oc_sessionPassphrase=VgWi0pTZfdyyH9JcC7ToP3xbnhjtWRtvdVqWAlw9XnrWI39geqNHNQVDktwnqYT17IyBUf6CQ8qq5j9VP8XyYy6BZ67XKdSGqK2CulQ2DUXuB0xPv8ArqfzEo6%2BP2H%2Bk; path=/core; HttpOnly; SameSite=Strict
Content-Security-Policy: default-src 'none';
Set-Cookie: oc5soe2gvutv=9j8ubda307o9od17chu18flv2c; path=/core; HttpOnly; SameSite=Strict
Set-Cookie: cookie_test=test; expires=Fri, 12-Nov-2021 07:12:22 GMT; Max-Age=3600
Content-Length: 243
Content-Type: application/xml; charset=utf-8

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\Conflict</s:exception>
  <s:message>Files cannot be created in non-existent collections</s:message>
</d:error>

Actual behavior

This is current OCIS behaviour

Host: localhost:9200
User-Agent: GuzzleHttp/7
Content-Length: 13
Authorization: basic QnJpYW46MTIzNA==
Ocs-Apirequest: true
X-Access-Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJyZXZhIiwiZXhwIjoxNjM2Njk3MTQxLCJpYXQiOjE2MzY2OTcwODEsImlzcyI6Imh0dHBzOi8vbG9jYWxob3N0OjkyMDAiLCJ1c2VyIjp7ImlkIjp7ImlkcCI6Imh0dHBzOi8vbG9jYWxob3N0OjkyMDAiLCJvcGFxdWVfaWQiOiJCcmlhbiJ9LCJ1c2VybmFtZSI6IkJyaWFuIiwibWFpbCI6ImJyaWFuQGV4YW1wbGUub3JnIiwibWFpbF92ZXJpZmllZCI6dHJ1ZSwiZGlzcGxheV9uYW1lIjoiQnJpYW4gTXVycGh5IiwiZ3JvdXBzIjpbInVzZXJzIl0sIm9wYXF1ZSI6eyJtYXAiOnsicm9sZXMiOnsiZGVjb2RlciI6Impzb24iLCJ2YWx1ZSI6Ild5SmtOMkpsWldWaE9DMDRabVkwTFRRd05tSXRPR1ppTmkxaFlqSmtaRGd4WlRaaU1URWlYUT09In19fSwidWlkX251bWJlciI6MjAwMDYsImdpZF9udW1iZXIiOjMwMDAwfSwic2NvcGUiOnsidXNlciI6eyJyZXNvdXJjZSI6eyJkZWNvZGVyIjoianNvbiIsInZhbHVlIjoiZXlKd1lYUm9Jam9pTHlKOSJ9LCJyb2xlIjoxfX19.BHqrgo_BKLPT4QElsh1ZJqlgujb3-Iy4dgQFz5pzQms
X-Request-Id: bb547d30-4fd0-401c-8cc3-ed38afd14a2e
Accept-Encoding: gzip

doesnotmatter

HTTP/1.1 403 Forbidden
Access-Control-Allow-Origin: *
Content-Security-Policy: default-src 'none';
Vary: Origin
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Robots-Tag: none
X-Xss-Protection: 1; mode=block
Date: Fri, 12 Nov 2021 06:04:41 GMT
Content-Length: 0 ``` 

[micbar]

Current ocis behavior is ok IMO.

@SwikritiT Can you point out why this could be a problem for the end user?

[phil-davis]

Yes, IMO the current oCIS behavior is OK (actually it is good - 403 Forbidden is correct)

It is strange that oC10 happens to return 409 Conflict with a Sabre exception Sabre\DAV\Exception\Conflict and message "Files cannot be created in non-existent collections". In oC10 the code path probably does not "see" the PARENT folder because Brian is Forbidden to see the PARENT folder of Alice.

It would be nice if the oC10 code path noticed first that Brian is Forbidden in general to access the WebDav endpoint of Alice.

I suggest that we:

• open an issue about the oC10 behavior
• adjust the real test in oC10 to expect the oCIS behavior, and skip that in oC10
• add a bug-demo scenario in oC10 (and skip that on oCIS)
• bump the core commit-id in oCIS (so that we can remove the entry for this issue from oCIS expected-failures)
• close this oCIS issue

@SwikritiT can you have a look please. (Let me know if my suggestion is rubbish)

[SwikritiT]

Yes, IMO the current oCIS behavior is OK (actually it is good - 403 Forbidden is correct)

It is strange that oC10 happens to return 409 Conflict with a Sabre exception Sabre\DAV\Exception\Conflict and message "Files cannot be created in non-existent collections". In oC10 the code path probably does not "see" the PARENT folder because Brian is Forbidden to see the PARENT folder of Alice.

It would be nice if the oC10 code path noticed first that Brian is Forbidden in general to access the WebDav endpoint of Alice.

I suggest that we:

• open an issue about the oC10 behavior
• adjust the real test in oC10 to expect the oCIS behavior, and skip that in oC10
• add a bug-demo scenario in oC10 (and skip that on oCIS)
• bump the core commit-id in oCIS (so that we can remove the entry for this issue from oCIS expected-failures)
• close this oCIS issue

@SwikritiT can you have a look please. (Let me know if my suggestion is rubbish)

That sounds good. I'll do as you suggested

[phil-davis]

core issue is owncloud/core#39597 - closing here as the "problem" is in core.

The core API tests have been updated, and the core commit id update is in oCIS PR #2881