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

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

    XMLWordPrintable

Details

    • Bug
    • Status: Open (View Workflow)
    • Major
    • Resolution: Unresolved
    • core
    • None

    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

          jpyeron Jason Pyeron added a comment -

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

          jpyeron Jason Pyeron added a comment - My colleagues say I have a non-IT cloud over my head.
          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.

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

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

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

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

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

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

          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.

          People

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

            Dates

              Created:
              Updated: