Different access checks in WebDAV versus in CIFS and Share UI

[p_bodnar]

Hi,

while playing with WebDAV (the near future replacement of CIFS according to https://community.alfresco.com/community/ecm/blog/2017/11/03/moving-from-smb-to-webdav?), I noticed that when trying to access a node (file, folder) via WebDAV, I can get to it even though I don't have have access (permissions) to every single parent node in the node's path. This is contrary to what can be seen when browsing via CIFS or the Share UI.

So my question is: Where does this difference come from and whether we can rely on this being unchanged in the future? Is it because "someone just thought it could be the best", or is it based on requirements given by specifications of the various file protocols?

[janv]

Hi Petr,

Great question. The underlying Alfresco Repository (ACS) permissions have always allowed user's with read permission on a node to be able to lookup & access it directly by node id, irrespective of whether a user has read permission on each node in the primary path (ie. primary parent/child associations).

In the case of lookup / access by node path (whether via name path or qname path), I believe this would be expected behaviour, although I haven't had a chance to double-check (each of the common path-based access options, such as via WebDAV, FTP, CMIS & even the public REST API for 5.2+). It would require the user to have prior knowledge of the node path.

Hence, as you day, using path-based protocol, such as WebDAV, they may be able to go directly to that node - given the url. However, they should not be able to navigate "up the path". Note: if this were forbidden then it would only be possible to navigate to the file by node id (hence not via WebDAV url).

If you wish to clarify that this will remain part of the public contract (for WebDAV &/other path-based access) then please contact customer support (if you have an Enterprise subscription) or else raise an ALF JIRA.

In the meantime, I'll see if I can find some time to scan the code base (& also check forums / JIRA to see if this question has been previously asked).

Regards,

Jan

[afaust]

I may not get a specific detail, but this behaviour has always been that way even in CIFS and Share. Access by ID and exact path was/is allowed by READ, but navigating TO it will fail if at any point in the path READ is not granted. The problem may be that a WebDAV (or other protocol) clients may perform an iterative lookup like a navigation even if an exact path is provided, so the client fails when it tries to access the first inaccessible intermediary path element.

[janv · Accepted solution]

Axel Faust‌ Agreed. In CIFS & Share UI DocLib, it is not possible to navigate down the path (ie. folders for which you do not have permission will not be visible).

Petr Bodnár‌ Can you please clarify with an example of how you used WebDAV to access the final node (folder or file). Did you use Browser or a client such as CyberDuck or some other mechanism ?

Thanks,

Jan

ps. also found this [MNT-7483] Inconsistent access criteria for CIFS vs. WebDav w.r.t. ancestor access permissions - Alf... 

[janv]

Also, on a related note, if you use the new public REST API (5.2+) to list children:

Alfresco Content Services REST API Explorer 

with query param "include=path", you will note that primary parent path is returned. However, if a parent is not accessible then it will be incomplete (with flag isComplete=false):

alfresco-core.yaml (PathInfo) 

Regards,

Jan

[p_bodnar]

Hi Jan,

the issue MNT-7483 you link to describes exactly the problem discussed in here, great you found it! Maybe I need to google (jira-search) for it better next time...

Apart from exactly describing my scenario, it also says that the ckecking behavior is maybe really stated in the CIFS specification somewhere. ( , there is actually no "iterative lookup like a navigation even if an exact path is provided", Alfresco's CifsHelper class does this "iterative lookup" itself, a client just sends the exact path.)

So I think we can close this question now as an answered one

[afaust]

I depends on the client and how they operate on a path / folder structure. I worked with a customer using AutoCAD in ~2012 and that application did do an iterative lookup. This became apparent when the underlying network packages were inspected. Sure, a client just sends a path, but the logic about which path is sent is still up to the client (i.e. how it operates on the file system view).

[p_bodnar]

OK, for you for your insight. Still, the important point in here is that the server side does the parents check anyway, no matter which "crazy client" accesses it...