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

Promoted-builds not following jenkins access control policies

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • promoted-builds-plugin
    • None
    • Jenkins head release with updated plugins on Ubuntu 11.10

      If the jenkins master config setting is set to "Logged in users can do anything", I would expect that to apply to build promotions as well.
      Instead, if there's no user restriction on the build promotion setting, non-logged-in users can still promote builds.

          [JENKINS-13975] Promoted-builds not following jenkins access control policies

          Since there are a lot of AuthorizationStrategy'ies in Jenkins,
          it's not a good idea to distinguish FullControlOnceLoggedInAuthorizationStrategy.

          What do you think '!' notation.
          For instance, "!anonymous" allows non-anonymous users to approve,
          and "group1,!user1" allows members in group1 except user1 to approve.

          Implementation would be https://github.com/jenkinsci/promoted-builds-plugin/compare/jenkinsci:1653a48...ohtake:9c9ab04

          OHTAKE Tomohiro added a comment - Since there are a lot of AuthorizationStrategy'ies in Jenkins, it's not a good idea to distinguish FullControlOnceLoggedInAuthorizationStrategy. What do you think '!' notation. For instance, "!anonymous" allows non-anonymous users to approve, and "group1,!user1" allows members in group1 except user1 to approve. Implementation would be https://github.com/jenkinsci/promoted-builds-plugin/compare/jenkinsci:1653a48...ohtake:9c9ab04

          Jose Sa added a comment -

          I would expect the promoted builds which are inside the context of a specific job to follow the authorized defined on job level (or global if Project Matrix is not in use), either using the "Update" permission or a specific "Promote" permission (if it exists)

          Jose Sa added a comment - I would expect the promoted builds which are inside the context of a specific job to follow the authorized defined on job level (or global if Project Matrix is not in use), either using the "Update" permission or a specific "Promote" permission (if it exists)

          Currently "Promote" permission is not defined. "Job.Build" or "Job.Configure" would be candidates if we do not define "Promote".

          In either case, I agree that using "Matrix-based security" or "Project-based Matrix Authorization Strategy" is a good idea. But we have to consider that a job might contain multiple promotion processes and that users want to set different approvers on them.

          Also we have to consider that no one has "Job.Build" permission, and that what users can do is only to approve. In that case, using matrix-based secuity will force users to change their configurations if they update the plugin.

          To avoid breaking changes, I prefer '!' notation.

          OHTAKE Tomohiro added a comment - Currently "Promote" permission is not defined. "Job.Build" or "Job.Configure" would be candidates if we do not define "Promote". In either case, I agree that using "Matrix-based security" or "Project-based Matrix Authorization Strategy" is a good idea. But we have to consider that a job might contain multiple promotion processes and that users want to set different approvers on them. Also we have to consider that no one has "Job.Build" permission, and that what users can do is only to approve. In that case, using matrix-based secuity will force users to change their configurations if they update the plugin. To avoid breaking changes, I prefer '!' notation.

          How about this one?
          "#Job.Build,user1" allows user1 and any user with Job.Build permission to approve.
          It enables us to do what this issue says.
          We have to decide which charactor is the best to denote permission later.

          OHTAKE Tomohiro added a comment - How about this one? "#Job.Build,user1" allows user1 and any user with Job.Build permission to approve. It enables us to do what this issue says. We have to decide which charactor is the best to denote permission later.

          Jose Sa added a comment -

          Regarding "!anonymous" there is actually a special group in Matrix or Project-Matrix Auth Strategy called "authenticated" that matches any logged-in user as a counterpart of "anonymous" (not logged-in).

          But it seems you are trying to define yet another Auth layer in each Promote Action. Wich makes sense if you want to override or complement the Authorizations in upper levels (Job or Global).

          Jose Sa added a comment - Regarding "!anonymous" there is actually a special group in Matrix or Project-Matrix Auth Strategy called "authenticated" that matches any logged-in user as a counterpart of "anonymous" (not logged-in). But it seems you are trying to define yet another Auth layer in each Promote Action. Wich makes sense if you want to override or complement the Authorizations in upper levels (Job or Global).

          I did not notice that there is "authenticated" group. It looks very usefull and there is no need of "!anonymous".

          And one more thing which I did not notice is that there has been "Promote" permission.
          https://github.com/jenkinsci/promoted-builds-plugin/blob/9542efcd0c2e6711f4ba9ec2336ee3d492994829/src/main/java/hudson/plugins/promoted_builds/Promotion.java#L183
          I will examine the current implementation of "Promote" permission.

          OHTAKE Tomohiro added a comment - I did not notice that there is "authenticated" group. It looks very usefull and there is no need of "!anonymous". And one more thing which I did not notice is that there has been "Promote" permission. https://github.com/jenkinsci/promoted-builds-plugin/blob/9542efcd0c2e6711f4ba9ec2336ee3d492994829/src/main/java/hudson/plugins/promoted_builds/Promotion.java#L183 I will examine the current implementation of "Promote" permission.

          I have dug commit logs.

          Unfortunately "Promote" permission is not designed to be used in manual promotion.
          Any ideas on behavior of empty manual approvers?

          • (Non-breaking change) Add help text which says "If textbox is empty, anyone who can read the job can approve builds."
          • (Breaking change) Define a new permission "Promotion.Approve". If approvers are not specified, users who have "Promotion.Approve" can approve. Note that permission cannot be specified for each promotion process separately.
          • (Breaking change, A lot of work required) Define a new permission "Promotion.Approve" and a new PermissionScope.
          • Any other idea?

          OHTAKE Tomohiro added a comment - I have dug commit logs. promoted-builds-1.1 "Promote" permission is introduced to restrict "Force promotion" and "Re-execute promotion" https://github.com/jenkinsci/promoted-builds-plugin/commit/83a9a500db6846d93f250b643b63f30165d0a46c (The link in the commit log is now 404) promoted-builds-2.0 Manual promotion supports user and group https://github.com/jenkinsci/promoted-builds-plugin/commit/9b8c399513e96bc2c8219fb50d65dde655681e34 Unfortunately "Promote" permission is not designed to be used in manual promotion. Any ideas on behavior of empty manual approvers? (Non-breaking change) Add help text which says "If textbox is empty, anyone who can read the job can approve builds." (Breaking change) Define a new permission "Promotion.Approve". If approvers are not specified, users who have "Promotion.Approve" can approve. Note that permission cannot be specified for each promotion process separately. (Breaking change, A lot of work required) Define a new permission "Promotion.Approve" and a new PermissionScope. Any other idea?

          eguess74 added a comment -

          Is there any progress with that one? It is still allowing to promote build using Approve button even if the user is NOT logged in.

          Thanks!

          eguess74 added a comment - Is there any progress with that one? It is still allowing to promote build using Approve button even if the user is NOT logged in. Thanks!

          Liam Nichols added a comment -

          Its getting on for 2 years since this was reported, is anybody able to look into it?
          Thanks.

          Liam Nichols added a comment - Its getting on for 2 years since this was reported, is anybody able to look into it? Thanks.

            Unassigned Unassigned
            bedge Bruce Edge
            Votes:
            7 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: