[JIRA] (JENKINS-56016) Input Submitter parameter ignored

Input Submitter parameter ignored

Issue Type:	Bug
Assignee:	Unassigned
Components:	pipeline-input-step-plugin
Created:	2019-02-07 06:56
Environment:	Jenkins 2.151.0 Pipeline Input Step: 2.9
Priority:	Major
Reporter:	Adrian Wyssmann

I use the following snippet in my DSL pipeline

 
                                                                operators = "ldapUserGroup"
ChoiceParameterDefinition choice = new ChoiceParameterDefinition('continue', ['YES'] as String[], 'Description')
returnValue = input message: 'DEPLOY ?', 
                    parameters: [choice], 
                    submitter: operators, 
                    submitterParameter: 'approver'
 
                                                            

I am not part of the ldapUserGroup thus I would expect the pipeline not to continue. However the pipeline continues anyway.

 
                                                                07:39:05 Approved by Surname Lastname
[Pipeline] }

The same happens if i use a particular userID or list of userIDs rather than an ldapGroup

 
                                                                operators = "userID0001,userID0002"
ChoiceParameterDefinition choice = new ChoiceParameterDefinition('continue', ['YES'] as String[], 'Description')
returnValue = input message: 'DEPLOY ?', 
                    parameters: [choice], 
                    submitter: operators, 
                    submitterParameter: 'approver'
 
                                                            

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

papanito@wyssmann.com (JIRA)

unread,

Feb 7, 2019, 1:58:01 AM2/7/19

to jenkinsc...@googlegroups.com

Adrian Wyssmann updated an issue

Jenkins /

Input Submitter parameter ignored

Change By:	Adrian Wyssmann

I use the following snippet in my DSL pipeline

{code:java}

operators = "ldapUserGroup"
ChoiceParameterDefinition choice = new ChoiceParameterDefinition('continue', ['YES'] as String[], 'Description')
returnValue = input message: 'DEPLOY ?',
                    parameters: [choice],
                    submitter: operators,
                    submitterParameter: 'approver'

{code}

I am not part of the {{ldapUserGroup}} thus I would expect the pipeline not to continue. However the pipeline continues anyway.

{code:java}

07:39:05 Approved by Surname Lastname
[Pipeline] }

{code}

The same happens if i use a particular userID or list of userIDs rather than an ldapGroup

{code:java}

operators = "userID0001,userID0002"
ChoiceParameterDefinition choice = new ChoiceParameterDefinition('continue', ['YES'] as String[], 'Description')
returnValue = input message: 'DEPLOY ?',
                    parameters: [choice],
                    submitter: operators,
                    submitterParameter: 'approver'

{code}

papanito@wyssmann.com (JIRA)

unread,

Feb 7, 2019, 3:22:02 AM2/7/19

to jenkinsc...@googlegroups.com

Adrian Wyssmann commented on

Apparently, me as an administrator can answer the question. Other users, which are not administrator are rejected when answering the question.

Is this the expected behaviour? If yes, I did not see this in the documentation, thus it would be good to mention this behaviour.

omit.rathore@gmail.com (JIRA)

unread,

Jun 7, 2019, 5:33:02 PM6/7/19

to jenkinsc...@googlegroups.com

Omit Rathore commented on

This is very dangerous issue , team relying on permissions control with submitter is broken. We had to revert to 2.8 .

Ideal flow would be only user/team should be allowed to proceed. it is classical example of privilege escalation. It is kind of security threat.

omit.rathore@gmail.com (JIRA)

unread,

Jun 7, 2019, 6:19:02 PM6/7/19

to jenkinsc...@googlegroups.com

Omit Rathore edited a comment on

This is very dangerous issue , team relying on permissions control with submitter is broken. We had to revert to 2.8 .

Ideal flow would be only user/team mentioned as submitter should be allowed to proceed. it It is classical example of privilege escalation. It is kind of security threat.

It's fine to have these feature if submitter is not mentioned.

wfollonier@cloudbees.com (JIRA)

unread,

Sep 6, 2019, 5:50:02 AM9/6/19

to jenkinsc...@googlegroups.com

Wadeck Follonier commented on

It seems that's the expected behavior due to https://issues.jenkins-ci.org/browse/JENKINS-48998. If you're an admin, you bypass the regular check of submitter user/group.

Sam Van Oort could you confirm?

dnusbaum@cloudbees.com (JIRA)

unread,

Sep 6, 2019, 11:51:03 AM9/6/19

to jenkinsc...@googlegroups.com

Devin Nusbaum commented on