Status: Open (View Workflow)
config.xml contained <authorizationStrategy class="hudson.security.ProjectMatrixAuthorizationStrategy">, which relied on a failed plugin. As such the loading of Jenkins was halted. There was no ability to admin Jenkins from the web UI, such as downgrading the ofending plugin.
See thread https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtFuG9t_F4zL%3D7ncg53XdZG9dZD-GdWQ1dtTN53DrKjm8g%40mail.gmail.com
No, that would not disable securtiy. In fact the case which happened here, commenting out that block, resulted in no-access.
1. A stack trace would not be exposed to the users (or the internet, etc)
2. depending on what failed, some operations may still function.
3. there is a hope of being able to use the web UI to manage the ofending plugin.
But lets start with #1, giving out the file path to the whole internet saying, hey I have my files in this path if you would like to start your hacking attemptins on a known target.
Good to know, I'll recomend that be addded to the Jenkins STIG and I'll deploy it to our instances.
But what if that plugin fails? I still think that failing to read the config.xml or process a plugin dependent section should not "crash" Jenkins.
Most don't. Auth related ones are the only that break Jenkins in this way AFAIK. You've just been lucky.
So you want to effectively disable security and leave Jenkins and all of its data available to everyone with network access to Jenkins when the authorization/authentication plugins break in any way?
This appears to be a really bad idea.