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

REST API requires Job/Build permission

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: role-strategy-plugin
    • Labels:
      None
    • Environment:
      Jenkins LTS 2.222.1
      role-strategy-plugin 2.16
    • Similar Issues:

      Description

      After upgrading to Jenkins LTS 2.222.1 + role-strategy-plugin 2.16, REST API calls have stopped working. On the Log we can see
       

      2020-04-02 14:42:46.468+0000 [id=20318] INFO o.e.j.s.h.ContextHandler$Context#log: While serving http://XXXXXXXXXXX/jenkins/job/YYYYYY-pipeline/buildWithParameters: hudson.security.AccessDeniedException2: inetic is missing the Job/Build permission
      

      which is exactly what we get through the REST API

      inetic has Admin permissions granted to a role, set throuch role-strategy-plugin and is able to execute any jobs through the UI.

      We're using user+token for auth, which should not need Jenkins-Crumb header. Nevertheless, we've also tried user+password+crumb and user+token+crumb and we get the same results. We've also tried setting hudson.security.csrf.GlobalCrumbIssuerConfiguration.DISABLE_CSRF_PROTECTION to either true or false, but again, it makes no difference.

      May be the security hardening done on 2.222.1 / 2.204.6 affects the role-strategy-plugin?

      Only workaround found so far is to set global Read + Build permissions, however that allows every user to execute everything without being logged which is not so funny.

      EDIT: forgot to add, $JENKINS/whoAmI for user yields:

      Name:	INETIC
      IsAuthenticated?:	true
      Authorities:	* "authenticated"
      

        Attachments

          Issue Links

            Activity

            Hide
            alexhraber Alex Raber added a comment - - edited

            I have the same issue, 403's from github webhooks to jenkins api, which were previously succeeding (on 2.204.5). Failing on 2.222.1.

            I posted on JENKINS-59105 too just in case it's caused by that.

            Show
            alexhraber Alex Raber added a comment - - edited I have the same issue, 403's from github webhooks to jenkins api, which were previously succeeding (on 2.204.5). Failing on 2.222.1. I posted on JENKINS-59105 too just in case it's caused by that.
            Hide
            juanpablo Juan Pablo Santos Rodríguez added a comment -

            Hi,

            we were able to locate what's happening, seems that efectively there's a bug introduced in latests LTS / role-strategy-plugin versions:

            • The user id we were using on our API calls was "INETIC" (uppercased, as it is how it is set up on the active directory); this could be seen while debugging curl's request headers: "* Server auth using Basic with user 'INETIC'".
            • Response headers told something a bit different, though: "< X-You-Are-Authenticated-As: inetic" (note user id is lowercased here).
            • The "Manage Roles" screen assigns roles to INETIC no matter how you introduce the ID. Most probably, the user id is being fetched from the AD, which makes sense.
            • From within the API call, being authenticated as inetic, there are no roles assigned to it, as they are assigned to INETIC. Seems that this lowercasing wasn't happening before.
            • We've changed the API user (with its associated token) to another with a lowercased user id and our problems are gone.

            This wasn't happening on our previous Jenkins instance (2.204.2 LTS with role-strategy-plugin 2.14, IIRC). The issue seems to happen with newer Jenkins LTS instances + role-strategy plugin 2.15 and 2.16, don't know specifically where the bug / regression is lying..

            Show
            juanpablo Juan Pablo Santos Rodríguez added a comment - Hi, we were able to locate what's happening, seems that efectively there's a bug introduced in latests LTS / role-strategy-plugin versions: The user id we were using on our API calls was " INETIC" (uppercased, as it is how it is set up on the active directory); this could be seen while debugging curl's request headers: " * Server auth using Basic with user 'INETIC'" . Response headers told something a bit different, though: " < X-You-Are-Authenticated-As: inetic" (note user id is lowercased here). The "Manage Roles" screen assigns roles to INETIC no matter how you introduce the ID. Most probably, the user id is being fetched from the AD, which makes sense. From within the API call, being authenticated as inetic , there are no roles assigned to it, as they are assigned to INETIC . Seems that this lowercasing wasn't happening before. We've changed the API user (with its associated token) to another with a lowercased user id and our problems are gone. This wasn't happening on our previous Jenkins instance (2.204.2 LTS with role-strategy-plugin 2.14, IIRC). The issue seems to happen with newer Jenkins LTS instances + role-strategy plugin 2.15 and 2.16, don't know specifically where the bug / regression is lying..
            Hide
            alexhraber Alex Raber added a comment -

            Thanks Juan Pablo Santos Rodríguez for the info.

            I also updated JENKINS-59105 with how I'm reproducing and what I've done to try to fix locally:
            https://issues.jenkins-ci.org/browse/JENKINS-59105?focusedCommentId=388706&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-388706

            I suppose I could just create a new ticket, but it sounds like the issue is a split between these 2 tickets.

            Show
            alexhraber Alex Raber added a comment - Thanks Juan Pablo Santos Rodríguez for the info. I also updated JENKINS-59105 with how I'm reproducing and what I've done to try to fix locally: https://issues.jenkins-ci.org/browse/JENKINS-59105?focusedCommentId=388706&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-388706 I suppose I could just create a new ticket, but it sounds like the issue is a split between these 2 tickets.

              People

              Assignee:
              oleg_nenashev Oleg Nenashev
              Reporter:
              juanpablo Juan Pablo Santos Rodríguez
              Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated: