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

New Job-DSL syntax does not create permission entries

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Critical Critical
    • matrix-auth-plugin
    • None
    • Jenkins 2.414.3, Debian 12, all plugins at current versions, users/groups from AD

      While the new syntax works fine in JCasC for creating global permissions, it doesn't work at all in Job-DSL for creating project permissions. The following script creates a job containing only the two empty default permission rows ("Anonymous", "Authenticated Users") instead of the provided permission entries: 

      freeStyleJob('PermissionTest') {
  properties {
    authorizationMatrix {
      inheritanceStrategy {
        nonInheriting()
      }
      entries {
        group {
          name('authenticated')
          permissions([
            'Overall/Read'
          ])
        }
        group {
          name('adgroup')
          permissions([
            'Overall/Administer'
          ])
        }
        user {
          name('aduser')
          permissions([
            'Overall/Read'
          ])
        }
      }
    }
  }
}

          [JENKINS-72263] New Job-DSL syntax does not create permission entries

          Daniel Beck added a comment - - edited

          Are you using matrix-auth or azure-ad plugin for the permissions?

          Is this a regression (i.e., did it work with the pre-3.2 syntax)?

          Daniel Beck added a comment - - edited Are you using matrix-auth or azure-ad plugin for the permissions? Is this a regression (i.e., did it work with the pre-3.2 syntax)?

          Dirk Heinrichs added a comment -
          • It's matrix-auth AND active-directory, but NOT azure-ad.
          • I don't know, wanted to add permissions to some existing, Job-DSL created jobs when I realized there was a breaking update, so I did that first

          Dirk Heinrichs added a comment - It's matrix-auth AND active-directory, but NOT azure-ad. I don't know, wanted to add permissions to some existing, Job-DSL created jobs when I realized there was a breaking update, so I did that first

          Daniel Beck added a comment -

          The permissions you specified make no sense on job scope, so they do not appear.

          Daniel Beck added a comment - The permissions you specified make no sense on job scope, so they do not appear.

          Dirk Heinrichs added a comment - - edited

          Ok. I would expect an error message from Job-DSL, then. And indeed, if I change the above from "Overall/Read" to "Job/Read" and "Overall/Administer" to "Job/Administer", I do get a stack trace with the following error: 

          ...
Caused by: java.lang.IllegalArgumentException: Permission cannot be null for: PermissionEntry{type=GROUP, sid='adgroup'}
...

          which goes away if I change it further to "Job/Build". This also results in permission entries being created.

          BTW: It's quite hard to find any documentation about which permissions are available at all. One needs to create an entry with all permissions enabled via the UI, and then look this up in the JCasC browser to get all the names...

          Dirk Heinrichs added a comment - - edited Ok. I would expect an error message from Job-DSL, then. And indeed, if I change the above from "Overall/Read" to "Job/Read" and "Overall/Administer" to "Job/Administer", I do get a stack trace with the following error:  ... Caused by: java.lang.IllegalArgumentException: Permission cannot be null for : PermissionEntry{type=GROUP, sid= 'adgroup' } ... which goes away if I change it further to "Job/Build". This also results in permission entries being created. BTW: It's quite hard to find any documentation about which permissions are available at all. One needs to create an entry with all permissions enabled via the UI, and then look this up in the JCasC browser to get all the names...

          Daniel Beck added a comment -

          indeed, if I change the above from "Overall/Read" to "Job/Read" and "Overall/Administer" to "Job/Administer",

          Job/Administer doesn't exist. The ones you first used do exist (are just irrelevant for the context you used).

          It's quite hard to find any documentation about which permissions are available at all. One needs to create an entry with all permissions enabled via the UI, and then look this up in the JCasC browser to get all the names...

          The names exactly match what's shown in the corresponding UI (in English locale). The screenshot at https://www.jenkins.io/doc/book/security/managing-security/#authorization tells you roughly 30 permission names.

          Daniel Beck added a comment - indeed, if I change the above from "Overall/Read" to "Job/Read" and "Overall/Administer" to "Job/Administer", Job/Administer doesn't exist. The ones you first used do exist (are just irrelevant for the context you used). It's quite hard to find any documentation about which permissions are available at all. One needs to create an entry with all permissions enabled via the UI, and then look this up in the JCasC browser to get all the names... The names exactly match what's shown in the corresponding UI (in English locale). The screenshot at https://www.jenkins.io/doc/book/security/managing-security/#authorization tells you roughly 30 permission names.

          Daniel Beck added a comment - - edited

          I would expect an error message from Job-DSL, then.

          System log has something that looks like this:

          2023-11-07 12:04:55.870+0000 [id=142]    WARNING    o.j.p.m.AuthorizationContainer#add: Tried to add inapplicable permission Permission[class hudson.model.Hudson,Administer] for authenticated in com.cloudbees.hudson.plugins.folder.properties.AuthorizationMatrixProperty@25f4306a, skipping

          It's not a great message, but there's not more context to provide at this point. It tells you permission, user/group name, and (indirectly via class name) the kind of object it's attempted to be granted on.

          Daniel Beck added a comment - - edited I would expect an error message from Job-DSL, then. System log has something that looks like this: 2023-11-07 12:04:55.870+0000 [id=142]    WARNING    o.j.p.m.AuthorizationContainer#add: Tried to add inapplicable permission Permission [class hudson.model.Hudson,Administer] for authenticated in com.cloudbees.hudson.plugins.folder.properties.AuthorizationMatrixProperty@25f4306a, skipping It's not a great message, but there's not more context to provide at this point. It tells you permission, user/group name, and (indirectly via class name) the kind of object it's attempted to be granted on.

            danielbeck Daniel Beck
            dhs Dirk Heinrichs
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: