Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-2186

"Project-based Matrix Authorization Strategy" - weird behavior

    XMLWordPrintable

    Details

    • Type: Patch
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: _unsorted
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Description

      Global authorization (set up in in "Configure System") is ignored when a project
      has defined its own local authorization matrix. That seems to be wrong behavior,
      shouldn't the local authorization extend the global instead of overriding it?

        Attachments

          Issue Links

            Activity

            Hide
            mindless Alan Harder added a comment -

            Marking as PATCH.

            Show
            mindless Alan Harder added a comment - Marking as PATCH.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in hudson
            User: : kohsuke
            Path:
            trunk/hudson/main/core/src/main/java/hudson/security/AuthorizationMatrixProperty.java
            trunk/hudson/main/core/src/main/java/hudson/security/GlobalMatrixAuthorizationStrategy.java
            trunk/hudson/main/core/src/main/java/hudson/security/ProjectMatrixAuthorizationStrategy.java
            trunk/hudson/main/core/src/main/java/hudson/security/SidACL.java
            trunk/www/changelog.html
            http://fisheye4.cenqua.com/changelog/hudson/?cs=13654
            Log:
            [FIXED JENKINS-2186] In project-based matrix security, global setting should be inherited to per-job setting.
            IN 1.265.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: trunk/hudson/main/core/src/main/java/hudson/security/AuthorizationMatrixProperty.java trunk/hudson/main/core/src/main/java/hudson/security/GlobalMatrixAuthorizationStrategy.java trunk/hudson/main/core/src/main/java/hudson/security/ProjectMatrixAuthorizationStrategy.java trunk/hudson/main/core/src/main/java/hudson/security/SidACL.java trunk/www/changelog.html http://fisheye4.cenqua.com/changelog/hudson/?cs=13654 Log: [FIXED JENKINS-2186] In project-based matrix security, global setting should be inherited to per-job setting. IN 1.265.
            Hide
            mindless Alan Harder added a comment -

            Comment/question on the implementation in r13654:

            The inner class in SidACL.newInheritingACL calls child and
            parent.hasPermission(Sid,Permission) directly, so it bypasses
            _hasPermission(Authentication,Permission) in those SidImpl classes.

            Will it miss checking ANONYMOUS?

            Show
            mindless Alan Harder added a comment - Comment/question on the implementation in r13654: The inner class in SidACL.newInheritingACL calls child and parent.hasPermission(Sid,Permission) directly, so it bypasses _hasPermission(Authentication,Permission) in those SidImpl classes. Will it miss checking ANONYMOUS?
            Hide
            mindless Alan Harder added a comment -

            Here are the steps to see the ANONYMOUS problem:

            1. Global perms:
            Anonymous does not have Workspace permission
            UserX is either not listed, or does not have Workspace permission
            2. ProjectX perms:
            Anonymous does have Workspace permission
            UserX is listed and does not have Workspace permission

            When UserX logs in and visits some project that does not have any
            project-specific permission, he can see the workspace (it will use only root
            ACL, so anonymous is checked). But when UserX visits ProjectX it does not show
            the Workspace. He can logout and see the workspace as anonymous, however (since
            anonymous is the actual user, that row IS checked).

            Is this a bug? Seems a bit inconsistent to skip the extra ANONYMOUS check in
            the projects with project-specific permissions. Then again, if you grant
            something to Anonymous in a project, you can just check that same box in every
            other row..

            Show
            mindless Alan Harder added a comment - Here are the steps to see the ANONYMOUS problem: 1. Global perms: Anonymous does not have Workspace permission UserX is either not listed, or does not have Workspace permission 2. ProjectX perms: Anonymous does have Workspace permission UserX is listed and does not have Workspace permission When UserX logs in and visits some project that does not have any project-specific permission, he can see the workspace (it will use only root ACL, so anonymous is checked). But when UserX visits ProjectX it does not show the Workspace. He can logout and see the workspace as anonymous, however (since anonymous is the actual user, that row IS checked). Is this a bug? Seems a bit inconsistent to skip the extra ANONYMOUS check in the projects with project-specific permissions. Then again, if you grant something to Anonymous in a project, you can just check that same box in every other row..
            Hide
            mindless Alan Harder added a comment -
                • Issue 2444 has been marked as a duplicate of this issue. ***
            Show
            mindless Alan Harder added a comment - Issue 2444 has been marked as a duplicate of this issue. ***

              People

              Assignee:
              adphillips adphillips
              Reporter:
              mast76 mast76
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: