Move action is ignoring permissions for Create/Job

[jtaylor555]

Jenkins and plugins versions report

Environment

Jenkins: 2.541.3
OS: Linux - 6.1.0-35-amd64
Java: 21.0.2 - Oracle Corporation (OpenJDK 64-Bit Server VM)
---
Office-365-Connector:5.3.0
additional-metrics:207.v0407e7fe201b_
android-emulator:664.ve25e686a_c00b_
ant:520.vd082ecfb_16a_9
antisamy-markup-formatter:173.v680e3a_b_69ff3
apache-httpcomponents-client-4-api:4.5.14-269.vfa_2321039a_83
apache-httpcomponents-client-5-api:5.6-191.vb_47e2b_41c698
asm-api:9.9.1-189.vb_5ef2964da_91
audit-trail:436.vc0d1e79fc5a_3
authentication-tokens:1.144.v5ff4a_5ec5c33
authorize-project:2.0.0
bootstrap5-api:5.3.8-895.v4d0d8e47fea_d
bouncycastle-api:2.30.1.83-289.v8426fcd19371
branch-api:2.1280.v0d4e5b_b_460ef
build-name-setter:2.5.1
build-timeout:1.40
build-timestamp:1.1.1
built-on-column:1.5
caffeine-api:3.2.3-194.v31a_b_f7a_b_5a_81
checks-api:402.vca_263b_f200e3
cloud-stats:377.vd8a_6c953e98e
cloudbees-disk-usage-simple:256.v20ec4eb_884f1
cloudbees-folder:6.1079.vc0975c2de294
command-launcher:123.v37cfdc92ef67
commons-collections4-api:4.5.0-8.va_d5448ef9011
commons-compress-api:1.28.0-3
commons-lang3-api:3.20.0-109.ve43756e2d2b_4
commons-text-api:1.15.0-218.va_61573470393
configurationslicing:700.vd71e4a_3a_c0a_a_
copyartifact:795.ve8e151429b_27
credentials:1499.va_f0e811253a_6
credentials-binding:719.v80e905ef14eb_
data-tables-api:2.3.7-1534.v539d4edf109d
display-url-api:2.217.va_6b_de84cc74b_
durable-task:664.v2b_e7a_dfff66c
echarts-api:6.0.0-1247.vf3e35a_c1813f
eddsa-api:0.3.0.1-29.v67e9a_1c969b_b_
email-ext:1933.v45cec755423f
enhanced-metrics:1.6
external-monitor-job:223.vb_fddcf42c9b_3
external-workspace-manager:1.3.1
font-awesome-api:7.2.0-965.ve3840b_696418
git:5.10.1
git-client:6.6.0
git-parameter:462.vdcf3df2ed2ca_
git-server:137.ve0060b_432302
github:1.46.0
github-api:1.330-492.v3941a_032db_2a_
github-branch-source:1967.vdea_d580c1a_b_a_
gradle:2.19.1244.v1f9866817fec
groovy:537.v741a_5a_f1b_581
gson-api:2.13.2-173.va_a_092315913c
instance-identity:203.v15e81a_1b_7a_38
ionicons-api:94.vcc3065403257
jackson2-api:2.21.2-433.v6d50b_92cfe52
jackson3-api:3.1.1-68.v2a_4b_025ea_657
jakarta-activation-api:2.1.4-1
jakarta-mail-api:2.1.5-1
jakarta-xml-bind-api:4.0.6-12.vb_1833c1231d3
javadoc:354.vee1a_660b_4990
javax-activation-api:1.2.0-8
javax-mail-api:1.6.2-11
jaxb:2.3.9-143.v5979df3304e6
jdk-tool:83.v417146707a_3d
jjwt-api:0.11.5-120.v0268cf544b_89
job-restrictions:242.v6edda_c9e4ca_f
jobConfigHistory:1356.ve360da_6c523a_
joda-time-api:2.14.1-187.vdf2def02b_8a_1
jqs-monitoring:37.vf50a_82a_0b_f32
jquery:1.12.4-3
jquery3-api:3.7.1-619.vdb_10e002501a_
jsch:0.2.16-95.v3eecb_55fa_b_78
json-api:20251224-185.v0cc18490c62c
json-path-api:3.0.0-218.vcd4dd1355de2
jsoup:1.22.1-76.v9cdb_2456c0e3
junit:1403.vd9d1413fd205
ldap:807.v7d7de30930cf
leastload:66.v8720e4713836
lockable-resources:1487.vca_821c68f190
mailer:534.v1b_36f5864073
matrix-auth:3.2.9
matrix-project:870.v9db_fcfc2f45b_
metrics:4.2.37-494.v06f9a_939d33a_
mina-sshd-api-common:2.16.0-167.va_269f38cc024
mina-sshd-api-core:2.16.0-167.va_269f38cc024
monitoring:2.6.0
nodelabelparameter:851.vd94e5048d321
okhttp-api:5.3.2-200.vedb_720a_cf1f8
oss-symbols-api:442.v99039087229b_
pam-auth:1.12
parameter-separator:334.v1fc0e534c71d
parameterized-trigger:890.vc240a_a_e1217f
pipeline-build-step:584.vdb_a_2cc3a_d07a_
pipeline-github-lib:65.v203688e7727e
pipeline-graph-analysis:254.v0f63a_a_447dca_
pipeline-graph-view:819.ved496c19e082
pipeline-groovy-lib:787.ve2fef0efdca_6
pipeline-input-step:540.v14b_100d754dd
pipeline-milestone-step:138.v78ca_76831a_43
pipeline-model-api:2.2277.v00573e73ddf1
pipeline-model-definition:2.2277.v00573e73ddf1
pipeline-model-extensions:2.2277.v00573e73ddf1
pipeline-rest-api:2.39
pipeline-stage-step:322.vecffa_99f371c
pipeline-stage-tags-metadata:2.2277.v00573e73ddf1
pipeline-stage-view:2.39
pipeline-utility-steps:2.20.0
plain-credentials:199.v9f8e1f741799
plot:2.4.0
plugin-util-api:6.1192.v30fe6e2837ff
port-allocator:351.v7a_94cf6e4677
postbuild-task:78.v24529f1f5cdb_
prism-api:1.30.0-703.v116fb_3b_5b_b_a_a_
prometheus:852.v317db_5d17a_b_0
purge-job-history:74.vf21030329dda_
resource-disposer:0.25
role-strategy:848.va_a_ea_673cf0b_c
run-selector:1.1.1
scm-api:728.vc30dcf7a_0df5
script-security:1399.ve6a_66547f6e1
shiningpanda:0.24
simple-theme-plugin:230.v8b_fd91b_b_800c
snakeyaml-api:2.5-149.v72471e9c6371
snakeyaml-engine-api:3.0.1-5.vd98ea_ff3b_92e
ssh-agent:386.v36cc0c7582f0
ssh-credentials:361.vb_f6760818e8c
ssh-slaves:3.1097.v868116049892
ssh-steps:2.0.92.vb_a_0583935f9b_
sshd:3.384.vc89b_5e138cf9
strict-crumb-issuer:2.1.1
structs:362.va_b_695ef4fdf9
thinBackup:2.1.3
timestamper:1.30
token-macro:477.vd4f0dc3cb_cf1
trilead-api:2.284.v1974ea_324382
uno-choice:2.8.9
variant:70.va_d9f17f859e0
view-job-filters:406.va_0ec67147ee2
woodstox-core-api:7.1.1-1.v4d297985f397
workflow-aggregator:608.v67378e9d3db_1
workflow-api:1398.v67030756d3fb_
workflow-basic-steps:1098.v808b_fd7f8cf4
workflow-cps:4275.vb_0565eb_a_3d36
workflow-durable-task-step:1464.v2d3f5c68f84c
workflow-job:1571.vb_423c255d6d9
workflow-multibranch:821.vc3b_4ea_780798
workflow-scm-step:466.va_d69e602552b_
workflow-step-api:710.v3e456cc85233
workflow-support:1015.v785e5a_b_b_8b_22
ws-cleanup:0.49

What Operating System are you using (both controller, and any agents involved in the problem)?

The controller has Debian 12 and it was tested through a browser on Windows.

Reproduction steps

1. Remove Create/Job and Move/Job permissions from a folder for a specific user permission.
2. Switch to user with that permission
3. Navigate to user's folder where they have Create/Job and Move/Job.
4. Choose move job and select the folder you removed permissions from on the first step.

Expected Results

The folder should not even show up as an option to move to if the user does not have Create/Job or Move/Job permissions in that folder. It should not display.

Actual Results

Create and Move permissions are ignored for the targeted folder. The job appears in the folder.

Anything else?

Based on a normal write/create permissions, the folder should not be allowed as a target for moving items.

Are you interested in contributing a fix?

No response

[mawinter69]

There is no dedicated permission to move jobs so not clear what you mean by this.
The reproduction steps are not clear enough for me. Please specify the exact patterns that are used for the folder and jobs. Note that you might deny job/create on the folder itself but can still allow job creation inside the older when you have the restrict naming enabled.
It would be the job of the folders plugin to not show any folders where the user has no job create permission.
Strictly speaking role-strategy is not even aware of folders, classes from the folders plugin are only used in 2 macros but not in anyway when it comes to permission checking.

[jtaylor555]

Ok that makes sense with what I am seeing. Essentially I have the job/create permission unchecked on a folder but the folder still shows up as a destination to move the job to even though the user does not have permissions to create jobs within that folder.
Example:
Role
releaseContents | "(?i)release($|/.*)" Permissions assigned: job/build job/cancel job/discover job/read

The user has this role assigned to them. They should be able to run jobs (essentially the folder is approved code) but not create new jobs within the folder. This works as expected besides the user being able to move their jobs from their own folder (which they have control over) to the release folder (which they should not be able to move items to but they can).

So based on what you have told me is that this is not a bug but expected behavior and the only way to take away the ability to move things there would be to use the Cloud Bees paid Folders plugin that has those additional folder permission options?

Thanks, hopefully this is more clear. I am not the best at explaining. things.

[mawinter69]

Actually there is a dedicated permission Move. Must have missed that, sorry for the confusion.
But without the move pernimssion I don't see the Move link in the sidebar.

Maybe there is indeed a problem when the restrict project naming is enabled.

When disabled it worked as expected but when enabled I was able to move jobs despite not being allowed to create jobs at that location.
Need to investigate if and how I can prevent that.

[mawinter69]

Still it might be something that must be fixed in folders plugin

[jtaylor555]

Thanks for getting back to me so quick. So you were able to recreate it. I agree that it could be a folders plugin thing as well. I was honestly wondering if it was just not included in the community version and needed to have the paid version for the feature. The reason I reported it was because it didn't make sense from a logic standpoint as it seems the chosen permissions were being ignored. I guess just let me know what happens next then.

[mawinter69]

The problem only occurs when the Project Naming Strategy is set to Role based Naming Strategy in the global config. When this is enabled the check if someone has create permission is actually true at least for Root. Role-strategy explicitly checks for that case as you need to be able to create jobs that match an allowed pattern.
The folder plugin checks if you can add an item to the itemgroup (Jenkins itself or a folder) and if the user has create permission on the itemgroup (https://github.com/jenkinsci/cloudbees-folder-plugin/blob/ffc15558b070ff4cb24a8877b31917c22378affd/src/main/java/com/cloudbees/hudson/plugins/folder/relocate/StandardHandler.java#L183)
Jenkins always returns true here for canAdd https://github.com/jenkinsci/jenkins/blob/15ec93744317ce3835211bffe0a6419abbc04efe/core/src/main/java/jenkins/model/Jenkins.java#L3239 and then the permission check also returns true with the project naming strategy
For folders the canAdd also always returns true, from the code path it uses FolderProperty#allowsParentToHave (https://github.com/jenkinsci/cloudbees-folder-plugin/blob/ffc15558b070ff4cb24a8877b31917c22378affd/src/main/java/com/cloudbees/hudson/plugins/folder/FolderProperty.java#L48) and there are no implementations of that method in github (there might be in cloudbees own product) and the permission check in the end falls through to the global check and thus also returns true. Later there is no longer any permission check done
In the end https://github.com/jenkinsci/jenkins/blob/15ec93744317ce3835211bffe0a6419abbc04efe/core/src/main/java/hudson/model/Items.java#L597 is called that also allows the move in that case.
So I think there are several things that need to be fixed:

• in core the Items.move should perform a check against the naming strategy if the move leads to a name that is not allowed for the user

Then I see 2 possibilities

1. in core and folders plugin adjust the canAdd so that it also considers the project naming strategy
2. in folders plugin adjust the permitted method in the StandardHandler to check there against the project naming strategy. Though this has the problem that if there is another implementation of the RelocationHandler that might need a fix as well.

There then still might be something to fix here.

[jtaylor555]

I agree, both of those would be an improvement on what the current status is. Thank you for replying and breaking this down for me. Is this going to go on the list for improvement/fixes then?