core icon indicating copy to clipboard operation
core copied to clipboard

Different permissions reported by webdav for the same mount point.

Open jvillafanez opened this issue 2 years ago • 5 comments

Checked with the WND app

Steps to reproduce

  1. Setup an external mount point and check that the root folder of the mount point can't be updated nor deleted.
  2. Access the storage through the classic web UI
  3. Change the permissions in the backend so the mount point can be updated and deleted
  4. Ensure permissions are updated in the DB (you might need to trigger an update in the external storage and access again through ownCloud).
  5. Check the dav permissions reported in the ownCloud's root folder and in the mount point

Expected behaviour

The permissions should be the same

Actual behaviour

Permissions missmatch: Propfind to https://my.server/remote.php/dav/files/forestUser/

<?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>/remote.php/dav/files/forestUser/</d:href>
    <d:propstat>
      <d:prop>
        <d:getlastmodified>Thu, 29 Jul 2021 08:52:17 GMT</d:getlastmodified>
        <d:getetag>"9182665b4edd722faf13b66c46ac031c"</d:getetag>
        <d:resourcetype>
          <d:collection/>
        </d:resourcetype>
        <oc:fileid>13</oc:fileid>
        <oc:permissions>RDNVCK</oc:permissions>
        <oc:size>12675007</oc:size>
        <oc:tags/>
        <oc:favorite>0</oc:favorite>
        <d:lockdiscovery/>
        <oc:comments-unread>0</oc:comments-unread>
        <oc:owner-display-name>forestUser UwU</oc:owner-display-name>
        <oc:share-types/>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
    <d:propstat>
      <d:prop>
        <d:getcontenttype/>
        <d:getcontentlength/>
      </d:prop>
      <d:status>HTTP/1.1 404 Not Found</d:status>
    </d:propstat>
  </d:response>
  <d:response>
    <d:href>/remote.php/dav/files/forestUser/welcome.txt</d:href>
    <d:propstat>
      <d:prop>
        <d:getlastmodified>Thu, 29 Jul 2021 07:04:26 GMT</d:getlastmodified>
        <d:getetag>"88b31a0f2fa10a075f5cc0d0810baacc"</d:getetag>
        <d:getcontenttype>text/plain</d:getcontenttype>
        <d:resourcetype/>
        <oc:fileid>14</oc:fileid>
        <oc:permissions>RDNVW</oc:permissions>
        <oc:size>163</oc:size>
        <d:getcontentlength>163</d:getcontentlength>
        <oc:tags/>
        <oc:favorite>0</oc:favorite>
        <d:lockdiscovery/>
        <oc:comments-unread>0</oc:comments-unread>
        <oc:owner-display-name>forestUser UwU</oc:owner-display-name>
        <oc:share-types/>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
  </d:response>
  <d:response>
    <d:href>/remote.php/dav/files/forestUser/WND/</d:href>
    <d:propstat>
      <d:prop>
        <d:getlastmodified>Thu, 29 Jul 2021 08:52:17 GMT</d:getlastmodified>
        <d:getetag>"61026c4ce35f9"</d:getetag>
        <d:resourcetype>
          <d:collection/>
        </d:resourcetype>
        <oc:fileid>15</oc:fileid>
        <oc:permissions>MCK</oc:permissions>
        <oc:size>12674844</oc:size>
        <oc:tags/>
        <oc:favorite>0</oc:favorite>
        <d:lockdiscovery/>
        <oc:comments-unread>0</oc:comments-unread>
        <oc:owner-display-name>forestUser UwU</oc:owner-display-name>
        <oc:share-types/>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
    <d:propstat>
      <d:prop>
        <d:getcontenttype/>
        <d:getcontentlength/>
      </d:prop>
      <d:status>HTTP/1.1 404 Not Found</d:status>
    </d:propstat>
  </d:response>
</d:multistatus>

Propfind to https://my.server/remote.php/dav/files/forestUser/WND

<?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>/remote.php/dav/files/forestUser/WND/</d:href>
    <d:propstat>
      <d:prop>
        <d:getlastmodified>Thu, 29 Jul 2021 08:52:17 GMT</d:getlastmodified>
        <d:getetag>"61026c4ce35f9"</d:getetag>
        <d:resourcetype>
          <d:collection/>
        </d:resourcetype>
        <oc:fileid>15</oc:fileid>
        <oc:permissions>MDNVCK</oc:permissions>
        <oc:size>12674844</oc:size>
        <oc:tags/>
        <oc:favorite>0</oc:favorite>
        <d:lockdiscovery/>
        <oc:comments-unread>0</oc:comments-unread>
        <oc:owner-display-name>forestUser UwU</oc:owner-display-name>
        <oc:share-types/>
      </d:prop>
      <d:status>HTTP/1.1 200 OK</d:status>
    </d:propstat>
    <d:propstat>
      <d:prop>
        <d:getcontenttype/>
        <d:getcontentlength/>
      </d:prop>
      <d:status>HTTP/1.1 404 Not Found</d:status>
    </d:propstat>
  </d:response>
.......

Note that the permissions for the WND folder differ when asked from the root folder and when asked directly.

The permissions reported in the ownCloud's root folder are wrong.

Permissions seems to change the wrong way in https://github.com/owncloud/core/blob/7154ca04963358b5054ec09e03175c6c916db5c4/lib/private/Files/View.php#L1601-L1608

Server configuration

Operating system: ubuntu 20.04

Web server: apache 2.4

Database: mysql

PHP version: 7.2

ownCloud version: 10.8.0

Updated from an older ownCloud or fresh install: fresh install

Where did you install ownCloud from:

Signing status (ownCloud 9.0 and above):

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results into https://gist.github.com/ and puth the link here.

The content of config/config.php:

Log in to the web-UI with an administrator account and click on
'admin' -> 'Generate Config Report' -> 'Download ownCloud config report'
This report includes the config.php settings, the list of activated apps
and other details in a well sanitized form.

or 

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your ownCloud installation folder

*ATTENTION:* Do not post your config.php file in public as is. Please use one of the above
methods whenever possible. Both, the generated reports from the web-ui and from occ config:list
consistently remove sensitive data. You still may want to review the report before sending.
If done manually then it is critical for your own privacy to dilligently
remove *all* host names, passwords, usernames, salts and other credentials before posting.
You should assume that attackers find such information and will use them against your systems.

List of activated apps:

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your ownCloud installation folder.

Are you using external storage, if yes which one: local/smb/sftp/...

Are you using encryption: yes/no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

LDAP configuration (delete this part if not used)

With access to your command line run e.g.:
sudo -u www-data php occ ldap:show-config
from within your ownCloud installation folder

Without access to your command line download the data/owncloud.db to your local
computer or access your SQL server remotely and run the select query:
SELECT * FROM `oc_appconfig` WHERE `appid` = 'user_ldap';


Eventually replace sensitive data as the name/IP-address of your LDAP server or groups.

Client configuration

Browser:

Operating system:

Logs

Web server error log

Insert your webserver log here

ownCloud log (data/owncloud.log)

Insert your ownCloud log here

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log 
c) ...

jvillafanez avatar Jul 29 '21 13:07 jvillafanez

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Jan 26 '22 01:01 github-actions[bot]

@pmaier1 @micbar should we include this ticket in the support queue?

On the one hand, this seems potentially dangerous, but on the other hand I think it has been like this for a long time. We should at least investigate and check what options we have to fix this. At the moment, I don't know if it's an easy fix or we might need bigger changes.

jvillafanez avatar Jan 26 '22 08:01 jvillafanez

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

github-actions[bot] avatar Jul 26 '22 01:07 github-actions[bot]

@micbar is there a reason why you add this issue to the support/engineers board?

NannaBarz avatar Aug 01 '22 08:08 NannaBarz

I did this on @jvillafanez advice. Needs investigation.

micbar avatar Aug 01 '22 08:08 micbar

I can't reproduce the issue on 10.10.0 nor in master (f16ee06034a041433e53fb3d86145d29155ea3d9 - post 10.10.0). The issue seems to be fixed, so closing.

jvillafanez avatar Aug 24 '22 11:08 jvillafanez