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

Loading config.xml sections dependent on failed plugins, must not crash Jenkins

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • core
    • None

      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

          [JENKINS-27175] Loading config.xml sections dependent on failed plugins, must not crash Jenkins

          Daniel Beck added a comment -

          Loading config.xml sections dependent on failed plugins, must not disable Jenkins

          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.

          Daniel Beck added a comment - Loading config.xml sections dependent on failed plugins, must not disable Jenkins 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.

          Jason Pyeron added a comment -

          No, that would not disable securtiy. In fact the case which happened here, commenting out that block, resulted in no-access.

          Jason Pyeron added a comment - No, that would not disable securtiy. In fact the case which happened here, commenting out that block, resulted in no-access.

          Daniel Beck added a comment -

          In what way would that be an improvement over the current situation?

          Daniel Beck added a comment - In what way would that be an improvement over the current situation?

          Jason Pyeron added a comment -

          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.

          Jason Pyeron added a comment - 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.

          Daniel Beck added a comment -

          Daniel Beck added a comment - https://wiki.jenkins-ci.org/display/JENKINS/Suppress+Stack+Trace+Plugin

          Jason Pyeron added a comment -

          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.

          Jason Pyeron added a comment - 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.

          Daniel Beck added a comment -

          Most don't. Auth related ones are the only that break Jenkins in this way AFAIK. You've just been lucky.

          Daniel Beck added a comment - Most don't. Auth related ones are the only that break Jenkins in this way AFAIK. You've just been lucky.

          Jason Pyeron added a comment -

          My colleagues say I have a non-IT cloud over my head.

          Jason Pyeron added a comment - My colleagues say I have a non-IT cloud over my head.

            Unassigned Unassigned
            jpyeron Jason Pyeron
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: