Skip to content

Do not write stack trace to system log for unauthorized API access#340

Open
MarkEWaite wants to merge 2 commits into
jenkinsci:masterfrom
MarkEWaite:do-not-log-stack-trace-from-checkPermission
Open

Do not write stack trace to system log for unauthorized API access#340
MarkEWaite wants to merge 2 commits into
jenkinsci:masterfrom
MarkEWaite:do-not-log-stack-trace-from-checkPermission

Conversation

@MarkEWaite

@MarkEWaite MarkEWaite commented Jul 11, 2026

Copy link
Copy Markdown
Contributor

Do not write stack trace to system log for unauthorized API access

Fixes #339

Return an empty list instead of throwing an exception. Write a message and the exception to the logger of the class when the logging level is FINE.

SECURITY-3745 with the change in 496a59 adds a permission check that requires Item.BUILD permission in order to read the parameter values. It relies on the checkPermission() method to throw an exception. The exception is written to the Jenkins log.

The unguarded call to checkPermission() is a relatively common technique, but a user reported that it dramatically increases the size of their system logs. Refer to issue:

This pull request changes the behavior of the API when the request does not have permission. The security fix caused the API to return:

  "parameterDefinitions": []

The code in this commit returns:

  "parameterDefinitions": [
    {
      "_class": "net.uaznia.lukanus.hudson.plugins.gitparameter.GitParameterDefinition",
      "defaultParameterValue": {
        "_class": "net.uaznia.lukanus.hudson.plugins.gitparameter.GitParameterValue",
        "value": "jdk-17.0.19"
      },
      "description": "Choose tag to checkout",
      "name": "PRIVATE_TAG",
      "type": "GitParameterDefinition",
      "allValueItems": {
        "errors": [],
        "values": []
      }
    }
  ]

That means the default value for the parameter is now available to the read only user, when previously the default value was not available to the read only user.

I'd like an opinion from the @jenkinsci/jenkins-security-team before I merge this change, since the default value might be considered sensitive information.

Testing done

  • Confirmed that the stack trace is written to the Jenkins log by the latest release
  • Confirmed that the stack trace is not written to the Jenkins log by this change
  • Confirmed that the list of values is correctly not returned by this change
  • Noted that the default value is visible with this change

I'd also like a report from the issue submitter @PetersNils that the incremental build has been installed and confirmed to work in the environment that had the issue.

Submitter checklist

  • Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • Ensure that the pull request title represents the desired changelog entry
  • Please describe what you did
  • Link to relevant issues in GitHub or Jira
  • Link to relevant pull requests, esp. upstream and downstream changes
  • Ensure you have provided tests that demonstrate the feature works or the issue is fixed

Fixes jenkinsci#339

Advisory https://www.jenkins.io/security/advisory/2026-06-24/#SECURITY-3745
with the change in
jenkinsci@496a59f
adds a permission check that requires Item.BUILD permission in order to
read the parameter values.  It relies on the checkPermission() method
to throw an exception.  The exception is written to the Jenkins log.

The unguarded call to checkPermission() is a relatively common technique,
but a user reported that it dramatically increases the size of their
system logs.  Refer to issue:

* jenkinsci#339

Return an empty list instead of throwing an exception. Write a message and
the exception to the logger of the class when the logging level is FINE.

Changes the behavior of the API when the request does not have permission.
The security fix caused the API to return:

>       "parameterDefinitions": []

The code in this commit returns:

>       "parameterDefinitions": [
>         {
>           "_class": "net.uaznia.lukanus.hudson.plugins.gitparameter.GitParameterDefinition",
>           "defaultParameterValue": {
>             "_class": "net.uaznia.lukanus.hudson.plugins.gitparameter.GitParameterValue",
>             "value": "jdk-17.0.19"
>           },
>           "description": "Choose tag to checkout",
>           "name": "PRIVATE_TAG",
>           "type": "GitParameterDefinition",
>           "allValueItems": {
>             "errors": [],
>             "values": []
>           }
>         }
>       ]

That means the default value for the parameter is now available to the
read only user, when previously the default value was not available to
the read only user.

I'd like an opinion from the Jenkins security team before I merge this
change, since the default value might be considered sensitive information.

Testing done:

* Confirmed that the stack trace is written to the Jenkins log by the latest release
* Confirmed that the stack trace is not written to the Jenkins log by this change
* Confirmed that the list of values is correctly not returned by this change
* Noted that the default value is visible with this change
@MarkEWaite
MarkEWaite requested a review from a team as a code owner July 11, 2026 16:31
@MarkEWaite MarkEWaite added the bug Incorrect or flawed behavior label Jul 11, 2026
@MarkEWaite MarkEWaite self-assigned this Jul 11, 2026
@MarkEWaite
MarkEWaite requested a review from Copilot July 11, 2026 16:31

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adjusts how GitParameterDefinition handles unauthorized access to its exported allValueItems data so that Jenkins API calls from users without Job.BUILD do not generate controller log stack traces.

Changes:

  • Catch AccessDeniedException from job.checkPermission(Job.BUILD) inside doFillValueItems(...) and return ItemsErrorModel.EMPTY.
  • Log the denied access at Level.FINE instead of allowing the exception to propagate into Stapler export logging.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +740 to +742
LOGGER.log(Level.FINE, job.getDisplayName() + " " + e.getMessage(), e);
return ItemsErrorModel.EMPTY;
}
@MarkEWaite

Copy link
Copy Markdown
Contributor Author

@PetersNils have you installed the incremental build on your Jenkins controller to confirm that it behaves the way you expect?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Incorrect or flawed behavior

Projects

None yet

Development

Successfully merging this pull request may close these issues.

AccessDeniedException logging regression

2 participants