Re-sharing permissions are not properly followed

[SwikritiT]

Describe the bug

A clear and concise description of what the bug is.

Steps to reproduce

Steps to reproduce the behavior:

1. As user Einstein create resource folder_from_einstein
2. Share the resource with user Moss with permission 31

curl -vk -X POST -u einstein:relativity https://host.docker.internal:9200/ocs/v1.php/apps/files_sharing/api/v1/shares -d 'path=folder_from_einstein' -d 'shareType=0' -d'permissions=31' -d'shareWith=moss' 

3. As Moss accept the share

curl -vk -X POST -u moss:vista https://host.docker.internal:9200/ocs/v1.php/apps/files_sharing/api/v1/shares/pending/<share-id>

4. As Moss reshare the recently accepted share to user Marie with permission 17

curl -vk -X POST -u moss:vista https://host.docker.internal:9200/ocs/v1.php/apps/files_sharing/api/v1/shares -d 'path=folder_from_einstein' -d 'shareType=0' -d'permissions=17' -d'shareWith=marie' -d'reshares=true' -d 'space_ref=<id>'

5. As Marie accept the share

curl -vk -X POST -u marie:radioactivity https://host.docker.internal:9200/ocs/v1.php/apps/files_sharing/api/v1/shares/pending/<share-id>

6. Now as Marie share the resource back to user Einstein with role 17 (considering that Einstein is the owner of the resource feels a little weird that you can reshare the same resource to the owner with lower permission?)

curl -vk -X POST -u marie:radioactivity https://host.docker.internal:9200/ocs/v1.php/apps/files_sharing/api/v1/shares -d 'path=folder_from_einstein' -d 'shareType=0' -d'permissions=17' -d'shareWith=einstein' -d'reshares=true' -d 'space_ref=1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!b979b13d-85fb-4ac1-ad13-576b12da553a' 

7. As einstein accept the share

curl -vk -X POST -u einstein:relativity https://host.docker.internal:9200/ocs/v1.php/apps/files_sharing/api/v1/shares/pending/<share-id>

8. Now as Einstein create a folder inside the reshared folder inside the Share jail (Note this folder is shared with role viewer)

curl -vk -X MKCOL -u einstein:relativity https://host.docker.internal:9200/dav/spaces/<id>/TestFolder

log

curl -vk -X MKCOL -u einstein:relativity https://host.docker.internal:9200/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157$\4c510ada-c86b-4815-8820-42cdf82c3d51%\21b979b13d-85fb-4ac1-ad13-576b12da553a/TestFolder
*   Trying 127.0.0.1:9200...
* TCP_NODELAY set
* Connected to host.docker.internal (127.0.0.1) port 9200 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: O=Acme Corp; CN=OCIS
*  start date: Aug  4 09:32:18 2022 GMT
*  expire date: Aug  4 09:32:18 2023 GMT
*  issuer: O=Acme Corp; CN=OCIS
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Server auth using Basic with user 'einstein'
> MKCOL /dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51%21b979b13d-85fb-4ac1-ad13-576b12da553a/TestFolder HTTP/1.1
> Host: host.docker.internal:9200
> Authorization: Basic ZWluc3RlaW46cmVsYXRpdml0eQ==
> 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: Thu, 04 Aug 2022 10:24:18 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
< 
* Connection #0 to host host.docker.internal left intact

The folder gets created from the Api but on UI the `New` and `upload` button are disabled

Similarly, If you go one level inside TestFolder, you can create/upload/delete/.... resources even from the UI

9. Now again as Marie reshare the same resource to user Moss (the user that she got share from) with permission 17

curl -vk -X POST -u marie:radioactivity https://host.docker.internal:9200/ocs/v1.php/apps/files_sharing/api/v1/shares -d 'path=folder_from_einstein' -d 'shareType=0' -d'permissions=17' -d'shareWith=moss' -d'reshares=true' -d 'space_ref=<id>' 

The http status is 200 and ocs status is 996 with error message grpc create share request failed

log

curl -vk -X POST -u marie:radioactivity https://host.docker.internal:9200/ocs/v1.php/apps/files_sharing/api/v1/shares -d 'path=folder_from_einstein' -d 'shareType=0' -d'permissions=17' -d'shareWith=moss' -d'reshares=true' -d 'space_ref=1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!b979b13d-85fb-4ac1-ad13-576b12da553a' 
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 127.0.0.1:9200...
* TCP_NODELAY set
* Connected to host.docker.internal (127.0.0.1) port 9200 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: O=Acme Corp; CN=OCIS
*  start date: Aug  4 09:32:18 2022 GMT
*  expire date: Aug  4 09:32:18 2023 GMT
*  issuer: O=Acme Corp; CN=OCIS
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* Server auth using Basic with user 'marie'
> POST /ocs/v1.php/apps/files_sharing/api/v1/shares HTTP/1.1
> Host: host.docker.internal:9200
> Authorization: Basic bWFyaWU6cmFkaW9hY3Rpdml0eQ==
> User-Agent: curl/7.68.0
> Accept: */*
> Content-Length: 202
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 202 out of 202 bytes
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Length: 164
< Content-Type: text/xml; charset=utf-8
< Date: Thu, 04 Aug 2022 10:27:17 GMT
< Ocs-Api-Version: 1
< Vary: Origin
< 
<?xml version="1.0" encoding="UTF-8"?>
* Connection #0 to host host.docker.internal left intact
<ocs><meta><status>error</status><statuscode>996</statuscode><message>grpc create share request failed</message></meta></ocs>%  

But looks like the share is still created , if I go to the UI and check the resource's collaborator list as user einstein (owner of the resourceMoss is listed twice with roleviewerandeditor`

10. If I access the UI of Moss it gives me the option to accept or decline the again, also in share with indicator Moss is shown x times the resource has been shared, and the permission is still 31 I think because I can create resources

11. Upon sending the Get req to fetch the shares received by Moss the reshare from Marie is listed even though the API threw error message

curl -vk -X GET -u moss:vista https://host.docker.internal:9200/ocs/v1.php/apps/files_sharing/api/v1/shares\?shared_with_me\=true

log

{
  "ocs": {
    "meta": {
      "status": "ok",
      "statuscode": 100,
      "message": "OK"
    },
    "data": {
      "element": [
        {
          "id": "f8cfb325-be2b-4ddc-ae2c-aa83ec2fd2d8",
          "share_type": 0,
          "uid_owner": "marie",
          "displayname_owner": "Marie Skłodowska Curie",
          "additional_info_owner": "marie@example.org",
          "permissions": 17,
          "stime": 1659609050,
          "parent": "",
          "expiration": "",
          "token": "",
          "uid_file_owner": "einstein",
          "displayname_file_owner": "Albert Einstein",
          "additional_info_file_owner": "einstein@example.org",
          "state": 0,
          "path": "/Shares/folder_from_einstein",
          "item_type": "folder",
          "mimetype": "httpd/unix-directory",
          "storage_id": "shared::/Shares/folder_from_einstein",
          "storage": 0,
          "item_source": "1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!b979b13d-85fb-4ac1-ad13-576b12da553a",
          "file_source": "1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!b979b13d-85fb-4ac1-ad13-576b12da553a",
          "file_parent": "",
          "file_target": "/Shares/folder_from_einstein",
          "share_with": "moss",
          "share_with_user_type": 0,
          "share_with_displayname": "Maurice Moss",
          "share_with_additional_info": "moss@example.org",
          "mail_send": 0,
          "name": ""
        },
        {
          "id": "266ebac8-f7c9-4d10-928f-102b748600e4",
          "share_type": 0,
          "uid_owner": "einstein",
          "displayname_owner": "Albert Einstein",
          "additional_info_owner": "einstein@example.org",
          "permissions": 31,
          "stime": 1659606718,
          "parent": "",
          "expiration": "",
          "token": "",
          "uid_file_owner": "einstein",
          "displayname_file_owner": "Albert Einstein",
          "additional_info_file_owner": "einstein@example.org",
          "state": 0,
          "path": "/Shares/folder_from_einstein",
          "item_type": "folder",
          "mimetype": "httpd/unix-directory",
          "storage_id": "shared::/Shares/folder_from_einstein",
          "storage": 0,
          "item_source": "1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!b979b13d-85fb-4ac1-ad13-576b12da553a",
          "file_source": "1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!b979b13d-85fb-4ac1-ad13-576b12da553a",
          "file_parent": "",
          "file_target": "/Shares/folder_from_einstein",
          "share_with": "moss",
          "share_with_user_type": 0,
          "share_with_displayname": "Maurice Moss",
          "share_with_additional_info": "moss@example.org",
          "mail_send": 0,
          "name": ""
        },
        {
          "id": "db8b6854-a17f-4eff-8094-20833a28d3eb",
          "share_type": 0,
          "uid_owner": "marie",
          "displayname_owner": "Marie Skłodowska Curie",
          "additional_info_owner": "marie@example.org",
          "permissions": 17,
          "stime": 1659608837,
          "parent": "",
          "expiration": "",
          "token": "",
          "uid_file_owner": "einstein",
          "displayname_file_owner": "Albert Einstein",
          "additional_info_file_owner": "einstein@example.org",
          "state": 0,
          "path": "/Shares/folder_from_einstein",
          "item_type": "folder",
          "mimetype": "httpd/unix-directory",
          "storage_id": "shared::/Shares/folder_from_einstein",
          "storage": 0,
          "item_source": "1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!b979b13d-85fb-4ac1-ad13-576b12da553a",
          "file_source": "1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!b979b13d-85fb-4ac1-ad13-576b12da553a",
          "file_parent": "",
          "file_target": "/Shares/folder_from_einstein",
          "share_with": "moss",
          "share_with_user_type": 0,
          "share_with_displayname": "Maurice Moss",
          "share_with_additional_info": "moss@example.org",
          "mail_send": 0,
          "name": ""
        }
      ]
    }
  }
}

Expected behavior

1. It should not possible to reshare a resource with owner with permission lower than what the owner already has.
2. If it is possible to reshare the resource with owner with lower perm the permission should be followed properly
3. If the API is throwing the error message, the share shouldn't be created.

Actual behavior

As described in the steps to reproduce

Setup

Please describe how you started the server and provide a list of relevant environment variables or configuration files.

OCIS=latest

Additional context

Add any other context about the problem here.

[rhafer]

I just went through the above steps. And for me it already fails at step 6 with the current code. Marie can't reshare Einstein's folder with Einstein

6. Now as Marie share the resource back to user Einstein with role 17 (considering that Einstein is the owner of the resource feels a little weird that you can reshare the same resource to the owner with lower permission?)

curl -vk -X POST -u marie:radioactivity https://host.docker.internal:9200/ocs/v1.php/apps/files_sharing/api/v1/shares -d 'path=folder_from_einstein' -d 'shareType=0' -d'permissions=17' -d'shareWith=einstein' -d'reshares=true' -d 'space_ref=1284d238-aa92-42ce-bdc4-0b0000009157$4c510ada-c86b-4815-8820-42cdf82c3d51!b979b13d-85fb-4ac1-ad13-576b12da553a' 

The error I get is:

<ocs><meta><status>error</status><statuscode>996</statuscode><message>grpc create share request failed</message>
</meta></ocs>

Didn't find much helpful info in the logs yet.

[rhafer]

It seems that all of the share managers in reva already dis-allowed to reshare a resource with the owner of that resource. Apart from the "cs3" manger which was our default from beta4 to beta7.
"cs3" should be fixed with the above PR.

But we will also switch the default again (to "jsoncs3"), which has the check as well.