sending MKCOL requests to another or non-existing user's webDav endpoints as normal user should return 404

[amrita-shrestha]

Steps to reproduce

Steps to reproduce the behavior:

1. As user admin send MKCOL request to another user's endpoint
   curl -vk -X MKCOL -u admin:admin http://localhost/core/remote.php/dav/files/anu/Test | xmllint --format -

2. As user admin send MKCOL request to non-existing user's endpoint
   curl -vk -X MKCOL -u admin:admin http://localhost/core/remote.php/dav/files/nonexistent/Test | xmllint --format -

Expected behavior

the status code should be 404. Visit this lInk owncloud/ocis#3872 (comment) for more info

Actual behavior

• Returns status 403 for existing user
• Return status 409 non-existen user

`curl -vk -X MKCOL -u admin:admin http://localhost/core/remote.php/dav/files/anu/Test | xmllint --format -`

curl -vk -X MKCOL -u admin:admin http://localhost/core/remote.php/dav/files/anu/Test | xmllint --format -
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 127.0.0.1:80...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 80 (#0)
* Server auth using Basic with user 'admin'
> MKCOL /core/remote.php/dav/files/anu/Test HTTP/1.1
> Host: localhost
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< Date: Tue, 08 Nov 2022 06:16:12 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: ocdyemofowli=82k2al7rk5s86at5o9nod3sbbu; 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=9lMPlShWSOuv4sKHdcInmdm5FzRFq5oh1gVJcRtBAptqJplo%2FxImrE%2FGkaVc%2BaB6vnlNhFwDv91RbccXmaRrVkPkOfdgljZVUPH06qSkKRZv2%2FYcCS77d%2B9S%2B4PZbu4F; expires=Tue, 08-Nov-2022 06:36:12 GMT; Max-Age=1200; path=/core; HttpOnly; SameSite=Strict
< Content-Security-Policy: default-src 'none';
< Set-Cookie: ocdyemofowli=11n0q0rpkccdc4nua5iveoje72; path=/core; HttpOnly; SameSite=Strict
< Set-Cookie: cookie_test=test; expires=Tue, 08-Nov-2022 07:16:12 GMT; Max-Age=3600
< Content-Length: 230
< Content-Type: application/xml; charset=utf-8
< 
{ [230 bytes data]
100   230  100   230    0     0   2254      0 --:--:-- --:--:-- --:--:--  2254
* Connection #0 to host localhost left intact
<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\Forbidden</s:exception>
  <s:message>Permission denied to create directory</s:message>
</d:error>

[amrita-shrestha]

QA Todo:

• Adjust the oC10 responses from 403 to 404 in test as phil suggested in below comment [tests-only][full-ci]Refactor MCKOL request to non-existence user and to another users endpoint #40495
• Remove ocis closed issue from expected-failure sending MKCOL requests to another user's webDav endpoints as normal user gives 404 instead of 403 ocis#3872

[phil-davis]

If I try this to a non-existent user:
curl -vk -X MKCOL -u admin:admin http://localhost/core/remote.php/dav/files/nonexistent/Test | xmllint --format -

I get 409 Conflict

I did not expect that. I thought that I would get 404 Not found.

The aim should be that when trying to access the storage of another "user", I should get the same error code whether the other "user" exists or not.

I suppose that oCIS is always returning 404, whether the "user" exists or not?

Anyway, we need to look for test scenarios that send MKCOL to another user who exists, and to a username that does not exist. And make scenarios of both that expect 404 in both situations, skip them on oC10, and move the existing scenarios to be bug-demo scenarios that are skipped on oCIS.

[SagarGi]

@phil-davis as per the issue i have gone through:

For Core

1. sending MCKOL request by user1 to another user's user2 endpoint gives status of 403 forbidden
2. sending MCKOL request by user1 to another non-existence user's i-am-not-a-user endpoint gives status of 409 conflict.

For oCIS (for new webdav)

1. sending MCKOL request by user1 to another user's user2 endpoint gives status of 409 conflict.
2. sending MCKOL request by user1 to another non-existence user's i-am-not-a-user endpoint gives status of 409 conflict.

And spaces webdav seems to be returning 404 for both case

So basically with this comment owncloud/ocis#3872 (comment) owncloud/ocis#3872 (comment) owncloud/ocis#3872 (comment) the request has to end with 404 in any of the case.

I will be adjusting based on the above information in core.

[phil-davis]

Yes, as I understand the requirement, all these ways of trying to create a folder (MKCOL) in a place where there is no access, or does not exist, should return 404. That helps to hide (not expose) the existence or otherwise of the user, space, resource.

[SagarGi]

#40495 All tests have been added in this PR. So closing this issue.

[phil-davis]

This is still an issue in oC10 - the current implementation returns a mix of 403 and 409, when we would like it to always return 404.

I created issue #40519 that will need some development work.