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

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

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
      None
    • Similar Issues:

      Description

      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

        Attachments

          Activity

          Hide
          danielbeck 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.

          Show
          danielbeck 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.
          Hide
          jpyeron 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.

          Show
          jpyeron 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.
          Hide
          danielbeck Daniel Beck added a comment -

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

          Show
          danielbeck Daniel Beck added a comment - In what way would that be an improvement over the current situation?
          Hide
          jpyeron 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.

          Show
          jpyeron 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.
          Show
          danielbeck Daniel Beck added a comment - https://wiki.jenkins-ci.org/display/JENKINS/Suppress+Stack+Trace+Plugin
          Hide
          jpyeron 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.

          Show
          jpyeron 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.
          Hide
          danielbeck 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.

          Show
          danielbeck 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.
          Hide
          jpyeron Jason Pyeron added a comment -

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

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

            People

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

              Dates

              • Created:
                Updated: