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

New permission controlling ability to configure your own User

      An administrator may want to block access to /me/configure, for example to prevent users from changing their own display names.

      Currently this appears to be impossible, as User.doConfigSubmit calls User.checkPermission, not Jenkins.checkPermission, and User.getACL is implemented to give every user permission to configure himself, regardless of authorization strategy.

      User.doConfigSubmit should additionally check some newly introduced global permission (such as User.SELF_CONFIGURE) which would be on by default for all (authenticated) users but could be explicitly disabled.

      The tricky part is introducing such a permission and granting it by default, since new permissions are rejected by default, and this one should not be implied by any existing permission.

          [JENKINS-15484] New permission controlling ability to configure your own User

          Jesse Glick added a comment -

          Introduce permission in core, implied by ADMINISTER, disabled by default, called by User.getACL or User.doConfigSubmit only if enabled; then create a plugin which does nothing but enable the permission. Awkward but may work.

          Jesse Glick added a comment - Introduce permission in core, implied by ADMINISTER , disabled by default, called by User.getACL or User.doConfigSubmit only if enabled; then create a plugin which does nothing but enable the permission. Awkward but may work.

          Because of the compatibility issue, let's do it like how we did extended job configuration read permission — define the permission in core, deactived by default, and a custom plugin that enables it.

          At the same time, we start remembering negative permissions in our authorization strategies so that new permissions like this can be added later more naturally in future versions.

          Kohsuke Kawaguchi added a comment - Because of the compatibility issue, let's do it like how we did extended job configuration read permission — define the permission in core, deactived by default, and a custom plugin that enables it. At the same time, we start remembering negative permissions in our authorization strategies so that new permissions like this can be added later more naturally in future versions.

          Jesse Glick added a comment -

          Debatable whether the RFE as originally stated is a good idea. If you block access to /me/configure then you also prevent users from (a) retrieving (or resetting) their own API tokens, (b) adding per-user credentials.

          Probably a more limited restriction would suffice, on changing certain properties such as display name and email which would normally be retrieved from a security realm.

          Jesse Glick added a comment - Debatable whether the RFE as originally stated is a good idea. If you block access to /me/configure then you also prevent users from (a) retrieving (or resetting) their own API tokens, (b) adding per-user credentials. Probably a more limited restriction would suffice, on changing certain properties such as display name and email which would normally be retrieved from a security realm.

          Jesse Glick added a comment -

          Cf. JENKINS-16502 regarding compatibility.

          Jesse Glick added a comment - Cf.  JENKINS-16502 regarding compatibility.

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: