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

"Project-based Matrix Authorization Strategy" - weird behavior

    XMLWordPrintable

Details

    • Patch
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • _unsorted
    • None
    • Platform: All, OS: All

    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

          is blocking

          Patch - JENKINS-2745 Project-based perms granted to Anonymous not treated like "Everybody", just Anonymous

          • Major - Major loss of function.
          • Closed
          is duplicated by

          New Feature - A new feature of the product, which has yet to be developed. JENKINS-2444 Project security

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            View 8 older comments
            mindless Alan Harder added a comment -

            Marking as PATCH.

            mindless Alan Harder added a comment - Marking as PATCH.
            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.

            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.
            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?

            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?
            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..

            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..
            mindless Alan Harder added a comment -
                • Issue 2444 has been marked as a duplicate of this issue. ***
            mindless Alan Harder added a comment - Issue 2444 has been marked as a duplicate of this issue. ***

            People

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

              Dates

                Created:
                Updated:
                Resolved: