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

Bitbucket Team/Folder project: View Configuration pages shows Access Denied, Jenkins throws hudson.security.AccessDeniedException2

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Blocker
    • Resolution: Fixed
    • Environment:
    • Similar Issues:

      Description

      Summary:
      On a Jenkins instance where Security is set to "Logged in users can do anything," the logged in user admin is shown Access Denied: admin is missing the Job/Configure permission when viewing repositories inside of a Bitbucket Team project. At the same time this is shown, the Jenkins log shows a hudson.security.AccessDeniedException2.

      Steps to recreate:
      1. Go to Global Security, and set it to "Logged-in users can do anything."

      2. Set up a Bitbucket Team/Project job:

      3. Go through the Configuration screen and set up the project in a normal way:

      4. Verify that the project has been created:

      5. Verify that you can at least run some builds for repos inside of this Team Project. In this case I'm looking at a particular branch:

      6. (Optional) If you have shell access to the instance, tail -f the Jenkins log.

      7. Go back up to the top level of the project, select the drop down next to one of the repositories, and pick "View Configuration:"

      8. In the Branch Sources section, directly under the "Repository Name" pulldown, notice there's sort of a second Jenkins UI being shown, which says "Access Denied."

      9. The Jenkins log will display the following information on loading the View Configuration page:

      Jan 05, 2018 7:25:45 PM org.eclipse.jetty.server.handler.ContextHandler$Context log
      INFO: While serving http://172.18.40.95:8080/job/bitbucket-access-denied-demo/job/test-of-pull-requests/descriptorByName/com.cloudbees.jenkins.plugins.bitbucket.BitbucketSCMSource/fillRepositoryItems: hudson.security.AccessDeniedException2: admin is missing the Job/Configure permission
      

      This is an issue for two reasons. First, there shouldn't be this second UI at all. Second, it's not clear why a logged-in user on a system which has been set to "Logged in users can do anything" would be denied access to anything

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              bitwiseman Liam Newman
              Reporter:
              kshultz Karl Shultz
              Votes:
              27 Vote for this issue
              Watchers:
              34 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: