Uploaded image for project: 'Service Packs and Hot Fixes'
  1. Service Packs and Hot Fixes
  2. MNT-7483

Inconsistent access criteria for CIFS vs. WebDav w.r.t. ancestor access permissions

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Won't Fix
    • Affects Version/s: 3.4.3
    • Fix Version/s: None
    • Component/s: CIFS, JLAN
    • Labels:
      None

      Description

      [Problem]

      Users are not able to access contents of folders where they do not have permissions to access all folders preceding them in their path via CIFS. Via WebDav users are able to access folders they have permissions for regardless of permissions on parent folders.

      [Details]

      To demonstrate:
      Create nested folders Company Home/L1/L2/L3/L4
      Remove permission inheritance on L2 so that no users are explicitly allowed access
      Grant access to a user 'test' on folder L4

      Via CIFS direct access to L4 will not be possible as tested in Windows 7 and OSX 10.7:
      \\<host>\Alfresco\L1\L2\L3\L4\

      Via WebDav Access to L4 will be granted but attempting to access the parent folder results in a permission error:
      http://test:test@<host>:8080/alfresco/webdav/L1/L2/L3/L4/

      [Expected Result]

      Permission behavior consistent between access methods.

      [Actual Result]

      Permission behavior not consistent between access methods.

      [Additional Info]

      This could be the result of the CIFS protocol specification specifying that permissions on each path component must be checked although to my knowledge this is not the case.

        Attachments

          Issue Links

            Activity

            Hide
            mrogers Mark Rogers [X] (Inactive) added a comment - - edited

            So are we saying that WebDav is wrong? I don't see how it is correct to navigate through a folder that you don't have permissions to read.

            If we are tempted to go the other way CIFS (and ftp for that matter) can't work without access to details of the parent folder so to make it work would require showing a folder for which you don't have read permissions. I think there's a minefield if we choose that way. The specs may not be explicit about this (because they don't consider implementation details) but its pretty much ingrained in most filesystems.

            Do we need to worry about this? What's the problem we are trying to solve?

            Show
            mrogers Mark Rogers [X] (Inactive) added a comment - - edited So are we saying that WebDav is wrong? I don't see how it is correct to navigate through a folder that you don't have permissions to read. If we are tempted to go the other way CIFS (and ftp for that matter) can't work without access to details of the parent folder so to make it work would require showing a folder for which you don't have read permissions. I think there's a minefield if we choose that way. The specs may not be explicit about this (because they don't consider implementation details) but its pretty much ingrained in most filesystems. Do we need to worry about this? What's the problem we are trying to solve?
            Hide
            cnguyen Chi Nguyen added a comment -

            In a Linux file system, if you have 'x' permission on a directory, you can "cd" into that directory and get to its children (provided you have access to the children of course). However, if you don't have 'r' permission on that same directory, you will not be able to list that directory contents (e.g. doing 'ls -la' will give you nothing). The Unix 'x' permission for a folder is exactly like what we need here: "to be able to traverse to a child folder where you have access, but not be able do listing on the parent folder where you don't have read access".

            Show
            cnguyen Chi Nguyen added a comment - In a Linux file system, if you have 'x' permission on a directory, you can "cd" into that directory and get to its children (provided you have access to the children of course). However, if you don't have 'r' permission on that same directory, you will not be able to list that directory contents (e.g. doing 'ls -la' will give you nothing). The Unix 'x' permission for a folder is exactly like what we need here: "to be able to traverse to a child folder where you have access, but not be able do listing on the parent folder where you don't have read access".
            Hide
            mrogers Mark Rogers [X] (Inactive) added a comment - - edited

            Yes - we could consider something like UNIX's X permission for a folder - but its not part of the product at the moment and it has wide ranging implications. Another option may be to change the way files are mounted so a user can select which files are mounted and where - possibly controlling the mapping themselves.

            I've just seen a recently opened jira (ALF-12967) that concern share and ancestor access permissions. That is a similar problem. So there's an opportunity to fix more than just the filesystem permissions.

            Show
            mrogers Mark Rogers [X] (Inactive) added a comment - - edited Yes - we could consider something like UNIX's X permission for a folder - but its not part of the product at the moment and it has wide ranging implications. Another option may be to change the way files are mounted so a user can select which files are mounted and where - possibly controlling the mapping themselves. I've just seen a recently opened jira ( ALF-12967 ) that concern share and ancestor access permissions. That is a similar problem. So there's an opportunity to fix more than just the filesystem permissions.

              People

              • Assignee:
                closedissues Closed Issues
                Reporter:
                jcohorn jcohorn
                My watchers:
                Alan Davis, Andrew Hunt, Craig Tan, Dave Ward [X] (Inactive), Will Taylor [X] (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: