Creating a new folder which is a substring of Shares leads to "Unknown Error"

[michaelkrieger]

Describe the bug

It appears that certain folder names result in an unknown error

Steps to reproduce

Steps to reproduce the behavior:

On a fresh installation, logged in as the admin:admin default user

• I create a folder named "Share", and I receive an "Creating folder failed… Error: Unknown error". The folder is in fact created when I refresh.
• I then create a folder named "Testing123" and it creates just fine, along with most other different names.
• I then create "Shar" and I get the error again.
• Same with "Sha"

Expected behavior

I should be able to create this share.

Actual behavior

A clear and concise description of what happened.

Setup

    environment:
      - OCIS_INSECURE=false
      - OCIS_URL=https://ocis.mydomain.com:1234
      - OCIS_LOG_PRETTY=true
      - PROXY_TLS=false
      - IDP_LDAP_BIND_PASSWORD=idp
      - STORAGE_LDAP_BIND_PASSWORD=reva
      - OCIS_JWT_SECRET=Pive-Fumkiu4
      - STORAGE_TRANSFER_SECRET=replace-me-with-a-transfer-secret
      - OCIS_MACHINE_AUTH_API_KEY=change-me-please

Additional context

[phil-davis]

Output of the new test scenarios that I wrote in core PR owncloud/core#39719 :

Feature: create file or folder named similar to Shares folder
  As a user
  I want to be able to create files and folders when the Shares folder exists
  So that I can organise the files in my file system

  Background:                                                                                     # /srv/app/testrunner/tests/acceptance/features/apiWebdavProperties1/createFileFolderWhenSharesExist.feature:7
    Given the administrator has set the default folder for received shares to "Shares"            # OccContext::theAdministratorHasSetTheDefaultFolderForReceivedSharesTo()
    And auto-accept shares has been disabled                                                      # FeatureContext::autoAcceptSharesHasBeenDisabled()
    And these users have been created with default attributes and without skeleton files:         # FeatureContext::theseUsersHaveBeenCreatedWithDefaultAttributesAndWithoutSkeletonFiles()
      | username |
      | Alice    |
      | Brian    |
    And user "Alice" has created folder "/FOLDER"                                                 # FeatureContext::userHasCreatedFolder()
    And user "Alice" has shared folder "/FOLDER" with user "Brian" with permissions "read,update" # FeatureContext::userHasSharedFileWithUserUsingTheSharingApi()
    And user "Brian" has accepted share "/FOLDER" offered by user "Alice"                         # FeatureContext::userHasReactedToShareOfferedBy()

  Scenario Outline: create a folder with a name similar to Shares         # /srv/app/testrunner/tests/acceptance/features/apiWebdavProperties1/createFileFolderWhenSharesExist.feature:19
    Given using <dav_version> DAV path                                    # FeatureContext::usingOldOrNewDavPath()
    When user "Brian" creates folder "<folder_name>" using the WebDAV API # FeatureContext::userCreatesFolder()
    Then the HTTP status code should be "201"                             # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And as "Brian" folder "<folder_name>" should exist                    # FeatureContext::asFileOrFolderShouldExist()
    And as "Brian" folder "/Shares" should exist                          # FeatureContext::asFileOrFolderShouldExist()
    Examples:
      | dav_version | folder_name |
      | old         | /Share      |
        folder '/Share' expected to exist for user Brian but not found
        Failed asserting that false is true.
      | old         | /shares     |
      | old         | /Shares1    |
        folder '/Shares1' expected to exist for user Brian but not found
        Failed asserting that false is true.
      | new         | /Share      |
        folder '/Share' expected to exist for user Brian but not found
        Failed asserting that false is true.
      | new         | /shares     |
      | new         | /Shares1    |
        folder '/Shares1' expected to exist for user Brian but not found
        Failed asserting that false is true.

  Scenario Outline: create a file with a name similar to Shares                                   # /srv/app/testrunner/tests/acceptance/features/apiWebdavProperties1/createFileFolderWhenSharesExist.feature:35
    Given using <dav_version> DAV path                                                            # FeatureContext::usingOldOrNewDavPath()
    When user "Brian" uploads file with content "some text" to "<file_name>" using the WebDAV API # FeatureContext::userUploadsAFileWithContentTo()
    Then the HTTP status code should be "201"                                                     # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And the content of file "<file_name>" for user "Brian" should be "some text"                  # FeatureContext::contentOfFileForUserShouldBe()
    And as "Brian" folder "/Shares" should exist                                                  # FeatureContext::asFileOrFolderShouldExist()
    Examples:
      | dav_version | file_name |
      | old         | /Share    |
      | old         | /shares   |
      | old         | /Shares1  |
        HTTP status code 409 is not the expected value 201
        Failed asserting that 409 matches expected '201'.
      | new         | /Share    |
      | new         | /shares   |
      | new         | /Shares1  |
        HTTP status code 409 is not the expected value 201
        Failed asserting that 409 matches expected '201'.

  Scenario Outline: try to create a folder named Shares             # /srv/app/testrunner/tests/acceptance/features/apiWebdavProperties1/createFileFolderWhenSharesExist.feature:51
    Given using <dav_version> DAV path                              # FeatureContext::usingOldOrNewDavPath()
    When user "Brian" creates folder "/Shares" using the WebDAV API # FeatureContext::userCreatesFolder()
    Then the HTTP status code should be "405"                       # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And as "Brian" folder "/Shares" should exist                    # FeatureContext::asFileOrFolderShouldExist()
    And as "Brian" folder "/Shares/FOLDER" should exist             # FeatureContext::asFileOrFolderShouldExist()
    Examples:
      | dav_version |
      | old         |
        HTTP status code 201 is not the expected value 405
        Failed asserting that 201 matches expected '405'.
      | new         |
        HTTP status code 201 is not the expected value 405
        Failed asserting that 201 matches expected '405'.

  Scenario Outline: try to create a file named Shares                                         # /srv/app/testrunner/tests/acceptance/features/apiWebdavProperties1/createFileFolderWhenSharesExist.feature:63
    Given using <dav_version> DAV path                                                        # FeatureContext::usingOldOrNewDavPath()
    When user "Brian" uploads file with content "some text" to "/Shares" using the WebDAV API # FeatureContext::userUploadsAFileWithContentTo()
    Then the HTTP status code should be "409"                                                 # FeatureContext::thenTheHTTPStatusCodeShouldBe()
    And as "Brian" folder "/Shares" should exist                                              # FeatureContext::asFileOrFolderShouldExist()
    And as "Brian" folder "/Shares/FOLDER" should exist                                       # FeatureContext::asFileOrFolderShouldExist()
    Examples:
      | dav_version |
      | old         |
      | new         |

Those tests all pass in core oC10.

[phil-davis]

• creating a folder with a name shorter or longer than Shares fails.
• creating a file with a name longer than Shares fails. (a shorter file name, like Share seems to be ok!)
• trying to create a folder Shares returns 201 status, but Shares already exists, and in that case oc10 returns 405. So oCIS should really also return 405. Or we should decide the "correct" response status code for this case, and make both oC10 and oCIS behave the same.

[butonic]

hrmpf, great find. There are some places in the ocdav handler where we assemble a user namespace based on the mountpath of spaces. There is some back and forth prefix matching to determine how space mountpoints affect the filelisting. I bet there is a bug in there ... @kobergj and I wrote that code but it will take some time (as in days) before I can take a look.

[wkloucek]

@kobergj @phil-davis please confirm this is fixed, then we can close the issue :-)

[kobergj]

Yes. This is fixed. I'll close the issue

[phil-davis]

Looks good. Sha, Share, Shareszzz etc. all work now.

I can still create Shares - and the folder is created in the user's personal space.
$ curl -u brian:B123 -vk -X MKCOL https://localhost:9200/remote.php/dav/files/brian/Shares

But then an attempt to create a sub-folder fails:

$ curl -u brian:B123 -vk -X MKCOL  https://localhost:9200/remote.php/dav/files/brian/Shares/sub-folder
HTTP/1.1 409 Conflict
<d:error xmlns:d="DAV" xmlns:s="http://sabredav.org/ns"><s:exception>Sabre\DAV\Exception\Conflict</s:exception><s:message>intermediate collection does not exist</s:message></d:error>

That happens if Brian has received a share from someone else. Brian has a "pseudo-folder" called "Shares". A PROPFIND lists the pseudo-folder and shows the shares inside it. The "real" Shares folder that brian created cannot be accessed this way.

That is a separate "challenge" - there is this pseudo-folder called "Shares" that "appears" in the Personal name space, but is actually a "pointer" to the incoming received shares.

[SagarGi]

@phil-davis with webdav old and new we cannot create Shares folder in Personal Space but with webdav spaces we can create it.

With old and new webdav

for example: using old webdav

curl -u marie:radioactivity -vk -X MKCOL https://host.docker.internal:9200/remote.php/dav/files/marie/Shares

Response:

<?xml version="1.0" encoding="UTF-8"?>
* Connection #0 to host host.docker.internal left intact
<d:error xmlns:d="DAV" xmlns:s="http://sabredav.org/ns"><s:exception>Sabre\DAV\Exception\MethodNotAllowed</s:exception><s:message>The resource you tried to create already exists</s:message></d:error>

With spaces webdav

Response:

> MKCOL /dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157$f7fbf8c8-139b-4376-b307-cf0a8c2d0d9c/Shares HTTP/1.1
> Host: host.docker.internal:9200
> Authorization: Basic bWFyaWU6cmFkaW9hY3Rpdml0eQ==
> User-Agent: curl/7.68.0
> Accept: */*
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Mark bundle as not supporting multiuse
< HTTP/1.1 201 Created
< Access-Control-Allow-Origin: *
< Content-Length: 0
< Content-Security-Policy: default-src 'none';
< Date: Tue, 26 Jul 2022 08:57:24 GMT
< 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

shall we reopen this issue or create new since this issue seems to be related to substring for the Shares folder? And also same in the case for uploading a file name Shares

[phil-davis]

@SagarGi yes, please create a separate issue for the things that are still "unusual" or not correct.

Then people can comment about exactly what should and should not be possible.