I want to let users have privilege to change project's configuration (ex: change Maven gold or pom.xml's location or build frequency), but I don't want to let users to change the privilege configuration (ex: grant privilege to other users), is it possible to add the feature?

      I think there are 2 approachs
      1. Separate the "configuration" privilege to 2 privileges in project. => Every project has different people can change the privilege.
      2. Add one new global privilege for "privilege configuration". => Only specific user can change the privilege of all projects.

          [JENKINS-20208] Separate privilege of project configuration

          Dennys Hsieh added a comment -

          This is an ugly patch and can limit only administrator can edit the project privilege.
          Modify src\main\resources\hudson\security\AuthorizationMatrixProperty\config.jelly

           
          <j:jelly xmlns:j="jelly:core" xmlns:st="jelly:stapler" xmlns:d="jelly:define" xmlns:l="/lib/layout" xmlns:t="/lib/hudson" xmlns:f="/lib/form">
              <j:if test="${h.hasPermission(app.ADMINISTER)}">
                <f:optionalBlock name="useProjectSecurity" title="${%Enable project-based security}" checked="${instance!=null}" xmlns:local="local">
                  <st:include class="hudson.security.GlobalMatrixAuthorizationStrategy" page="config.jelly"/>
                </f:optionalBlock>
              </j:if>
          </j:jelly>
          

          Dennys Hsieh added a comment - This is an ugly patch and can limit only administrator can edit the project privilege. Modify src\main\resources\hudson\security\AuthorizationMatrixProperty\config.jelly <j:jelly xmlns:j = "jelly:core" xmlns:st = "jelly:stapler" xmlns:d = "jelly:define" xmlns:l = "/lib/layout" xmlns:t = "/lib/hudson" xmlns:f = "/lib/form" > <j:if test= "${h.hasPermission(app.ADMINISTER)}" > <f:optionalBlock name= "useProjectSecurity" title= "${%Enable project-based security}" checked= "${instance!=null}" xmlns:local = "local" > <st:include class= "hudson.security.GlobalMatrixAuthorizationStrategy" page= "config.jelly" /> </f:optionalBlock> </j:if> </j:jelly>

          Dennys Hsieh added a comment -

          The above patch doesn't work because if user doesn't see the configuration and he submit the configuration, the privilege will be cleared.
          This is my current solution

          Modify src\main\resources\hudson\security\AuthorizationMatrixProperty\config.jelly

           
          <j:jelly xmlns:j="jelly:core" xmlns:st="jelly:stapler" xmlns:d="jelly:define" xmlns:l="/lib/layout" xmlns:t="/lib/hudson" xmlns:f="/lib/form">
              <j:if test="${h.hasPermission(app.ADMINISTER)}">
                <f:optionalBlock name="useProjectSecurity" title="${%Enable project-based security}" checked="${instance!=null}" xmlns:local="local">
                  <st:include class="hudson.security.GlobalMatrixAuthorizationStrategy" page="config.jelly"/>
                </f:optionalBlock>
              </j:if>
              <j:if test="${!h.hasPermission(app.ADMINISTER)}">
                <f:optionalBlock name="useProjectSecurity" title="${%Enable project-based security}" checked="${instance!=null}" xmlns:local="local">
                  <st:include class="hudson.security.GlobalMatrixAuthorizationStrategy" page="config_readonly.jelly"/>
                </f:optionalBlock>
              </j:if>
          </j:jelly>
          

          Clone a file from src\main\resources\hudson\security\GlobalMatrixAuthorizationStrategy\config.jelly to config_readonly.jelly
          1. Modify line 36 to disable checkbox click

           
          <f:checkbox name="[${p.id}]" checked="${instance.hasExplicitPermission(attrs.sid,p)}" onclick="return false" />
          

          2. Delete line 41~50 to remove button

          Dennys Hsieh added a comment - The above patch doesn't work because if user doesn't see the configuration and he submit the configuration, the privilege will be cleared. This is my current solution Modify src\main\resources\hudson\security\AuthorizationMatrixProperty\config.jelly <j:jelly xmlns:j = "jelly:core" xmlns:st = "jelly:stapler" xmlns:d = "jelly:define" xmlns:l = "/lib/layout" xmlns:t = "/lib/hudson" xmlns:f = "/lib/form" > <j:if test= "${h.hasPermission(app.ADMINISTER)}" > <f:optionalBlock name= "useProjectSecurity" title= "${%Enable project-based security}" checked= "${instance!=null}" xmlns:local = "local" > <st:include class= "hudson.security.GlobalMatrixAuthorizationStrategy" page= "config.jelly" /> </f:optionalBlock> </j:if> <j:if test= "${!h.hasPermission(app.ADMINISTER)}" > <f:optionalBlock name= "useProjectSecurity" title= "${%Enable project-based security}" checked= "${instance!=null}" xmlns:local = "local" > <st:include class= "hudson.security.GlobalMatrixAuthorizationStrategy" page= "config_readonly.jelly" /> </f:optionalBlock> </j:if> </j:jelly> Clone a file from src\main\resources\hudson\security\GlobalMatrixAuthorizationStrategy\config.jelly to config_readonly.jelly 1. Modify line 36 to disable checkbox click <f:checkbox name= "[${p.id}]" checked= "${instance.hasExplicitPermission(attrs.sid,p)}" onclick= "return false" /> 2. Delete line 41~50 to remove button

          This seems to be open since 2013. Any updates? What are our options here?

          Daniel Anechitoaie added a comment - This seems to be open since 2013. Any updates? What are our options here?

          In my opinion it`s a security BLOCKER! Is it possible to fix this bug? Thanks

          Niko Madalinski added a comment - In my opinion it`s a security BLOCKER! Is it possible to fix this bug? Thanks

          yeah, pleeeease fix it !

          Thomas Leufkes added a comment - yeah, pleeeease fix it !

          Daniel Beck added a comment -

          dennys's proposed solution is flawed. Some JavaScript can make all the checkboxes writable again, not to mention just directly sending a patched response.

          Even checking permissions on the server side in newInstance and similar methods, and ignoring input if the permission is present, will not work; anyone with Job/Configure permission can POST config.xml or use the update-job CLI command and bypass those checks.

          While there are possible solutions to this, they're not this straightforward.

          Daniel Beck added a comment - dennys 's proposed solution is flawed. Some JavaScript can make all the checkboxes writable again, not to mention just directly sending a patched response. Even checking permissions on the server side in newInstance and similar methods, and ignoring input if the permission is present, will not work; anyone with Job/Configure permission can POST config.xml or use the update-job CLI command and bypass those checks. While there are possible solutions to this, they're not this straightforward.

          we would also like to have this option !   Only global admin or user/role with the permission should be able to configure permissions on a folder/project

          Bart Devriendt added a comment - we would also like to have this option !   Only global admin or user/role with the permission should be able to configure permissions on a folder/project

          I definitely agree that having a "Set Permission" additional permission is an important thing in order to avoid a security hole. Let a user configure a project shouldn't imply letting him granting access to other users/groups.

          Olivier Bonhomme added a comment - I definitely agree that having a "Set Permission" additional permission is an important thing in order to avoid a security hole. Let a user configure a project shouldn't imply letting him granting access to other users/groups.

            Unassigned Unassigned
            dennys Dennys Hsieh
            Votes:
            8 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: