• Separate the authorization configuration from the project configuration. This allows Jenkins to decide the authorization of builds during configuring projects.
      • When a plugin lists up credentials,
        public ListBoxModel doFillCredentialsIdItems(@AncestorInPath Job project) {
            Authentication auth = Tasks.getAuthenticationOf(project);
            return new StandardUsernameListBoxModel()
                .includeEmptyValue()
                .includeAs(auth, project, StandardUsernameCredentials.class);
        }
        
      • Even if the authorization is changed after the project configuration is saved, it doesn't cause a security issue as the access to the credential is blocked at build time.

      Issues:

      • How to control permissions to configure jobs
        • You don't want to allow other users configure jobs when you use "Run as Specific User".
      • Should the configuration file be separated from config.xml?

          [JENKINS-35081] Separate authorization configuration page

          ikedam created issue -
          ikedam made changes -
          Link New: This issue is related to JENKINS-31870 [ JENKINS-31870 ]

          ikedam added a comment -

          > How to control permissions to configure jobs

          Unfortunately, Jenkins doesn't provide a machanism to override ACLs of items.
          Only AuthorizationStrategy decides ACLs

          Possible solutions.

          • authorize-project provides a new AuthorizationStrategy wrapping other strategies.
            • authorize-project works only when that wrapping strategy is set to Jenkins.
          • Improve Jenkins, and add a mechanism to override ACLs by plugins.

          ikedam added a comment - > How to control permissions to configure jobs Unfortunately, Jenkins doesn't provide a machanism to override ACLs of items. Only AuthorizationStrategy decides ACLs Possible solutions. authorize-project provides a new AuthorizationStrategy wrapping other strategies. authorize-project works only when that wrapping strategy is set to Jenkins. Improve Jenkins, and add a mechanism to override ACLs by plugins.

          ikedam added a comment -

          I believe I can bind a custom configuration file to a job with TransientActionFactory.

          ikedam added a comment - I believe I can bind a custom configuration file to a job with TransientActionFactory .

          Here is the interim hack to make this safe on older Jenkins instances:

          Ok if you have a JobProperty that is @Extension(ordinal=Double.MAX_VALUE) then https://github.com/jenkinsci/jenkins/blob/jenkins-1.609/core/src/main/java/hudson/model/Job.java#L1193 should call https://github.com/jenkinsci/jenkins/blob/jenkins-1.609/core/src/main/java/hudson/model/ReconfigurableDescribable.java#L82 for that JobProperty if not first then at least very very early on in config submit.

          If you have the reconfigure method throw an authorization exception then that should prevent the job from being reconfigured.

          Here is the long term solution:

          Add a decorator interface like ReconfigurableDescribable that allows decorating the ACL, then in Job.getACL() iterate the list of job properties (in reverse order) for instances that implement that interface and then apply the decoration. (we want to iterate in reverse order so that the highest @Extension(ordinal) wins

          Hope that helps and avoids that AuthorizationStrategy hack you were thinking of.

          Stephen Connolly added a comment - Here is the interim hack to make this safe on older Jenkins instances: Ok if you have a JobProperty that is @Extension(ordinal=Double.MAX_VALUE) then https://github.com/jenkinsci/jenkins/blob/jenkins-1.609/core/src/main/java/hudson/model/Job.java#L1193 should call https://github.com/jenkinsci/jenkins/blob/jenkins-1.609/core/src/main/java/hudson/model/ReconfigurableDescribable.java#L82 for that JobProperty if not first then at least very very early on in config submit. If you have the reconfigure method throw an authorization exception then that should prevent the job from being reconfigured. Here is the long term solution: Add a decorator interface like ReconfigurableDescribable that allows decorating the ACL , then in Job.getACL() iterate the list of job properties (in reverse order) for instances that implement that interface and then apply the decoration. (we want to iterate in reverse order so that the highest @Extension(ordinal) wins Hope that helps and avoids that AuthorizationStrategy hack you were thinking of.

          For the hack you can have a AdministrativeMonitor check if the JobProperty is first and alert with the name of the plugin that won out if it isn't first saying something like "You are running Jenkins < 2.7 and the FooManchu plugin has declared a Job property of type FooManchuJobProperty with a higher priority than the AuthorizeProject plugin's job configuration protection. A user may be able to alter the configuration of the FooManchuJobProperty in cases where they should not. Please alert the maintainer of the FooManchu plugin. [DISMISS]"

          Stephen Connolly added a comment - For the hack you can have a AdministrativeMonitor check if the JobProperty is first and alert with the name of the plugin that won out if it isn't first saying something like "You are running Jenkins < 2.7 and the FooManchu plugin has declared a Job property of type FooManchuJobProperty with a higher priority than the AuthorizeProject plugin's job configuration protection. A user may be able to alter the configuration of the FooManchuJobProperty in cases where they should not. Please alert the maintainer of the FooManchu plugin. [DISMISS] "
          Stephen Connolly made changes -
          Link New: This issue is related to JENKINS-31870 [ JENKINS-31870 ]
          Stephen Connolly made changes -
          Description Original: * Separate the authorization configuration from the project configuration. This allows Jenkins to decide the authorization of builds during configuring projects.
          * When a plugin lists up credentials,
          {code}
          public ListBoxModel doFillCredentialsIdItems(@AncestorInPath Job project) {
              Authentication auth = Tasks.getAuthenticationOf(project);
              return new StandardUsernameListBoxModel().withEmptySelection().withAll(
                  CredentialsProvider.lookupCredentials(StandardUsernameCredentials.class, auth);
          }
          {code}
          * Even if the authorization is changed after the project configuration is saved, it doesn't cause a security issue as the access to the credential is blocked at build time.

          Issues:

          * How to control permissions to configure jobs
          ** You don't want to allow other users configure jobs when you use "Run as Specific User".
          * Should the configuration file be separated ftom config.xml?
          New: * Separate the authorization configuration from the project configuration. This allows Jenkins to decide the authorization of builds during configuring projects.
          * When a plugin lists up credentials,
          {code}
          public ListBoxModel doFillCredentialsIdItems(@AncestorInPath Job project) {
              Authentication auth = Tasks.getAuthenticationOf(project);
              return new StandardUsernameListBoxModel()
                  .includeEmptyValue()
                  .includeAs(auth, project, StandardUsernameCredentials.class);
          }
          {code}
          * Even if the authorization is changed after the project configuration is saved, it doesn't cause a security issue as the access to the credential is blocked at build time.

          Issues:

          * How to control permissions to configure jobs
          ** You don't want to allow other users configure jobs when you use "Run as Specific User".
          * Should the configuration file be separated ftom config.xml?
          ikedam made changes -
          Link New: This issue is blocked by JENKINS-13190 [ JENKINS-13190 ]
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 171295 ] New: JNJira + In-Review [ 184247 ]

            ikedam ikedam
            ikedam ikedam
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: