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

userContent *zip* (all files in zip) stopped working at 2.164

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
    • Environment:
      Windows 2008 R2 Enterprise, Jenkins 2.164+
    • Similar Issues:

      Description

      When using the (all files in zip) functionality starting at 2.164, either from the UI or URL (https:/myjenkins/userContent/*zip*/image.zip), the resulting image.zip has no content. 

      This has silently broken our builds, which utilize this functionality to retrieve certain content. Downgrading jenkins.war to 2.163 restores the functionality.

        Attachments

        1. image-2019-02-28-16-52-19-863.png
          7 kB
          Glenn Herbert
        2. image-2019-02-28-16-53-48-739.png
          3 kB
          Glenn Herbert
        3. image-2019-02-28-16-54-36-484.png
          6 kB
          Glenn Herbert
        4. image-2019-02-28-16-55-40-767.png
          2 kB
          Glenn Herbert

          Activity

          Hide
          arjo_poldervaart Arjo Poldervaart added a comment - - edited

          Our use is similar to that of Glenn. To provide some context:

          If we want to release an artifact to production, we tag it in our SCM and let Jenkins build it, Jenkins then copies the artifact to a different location so we can download it at a later time (even if the workspace is cleared). The copy is done via a symlink created in the workspace by our build script (soft link on Linux) to a folder outside the workspace on disk.

          When we want to deploy the artifact we can simply download it via een link like: /view/assets/job/assets-BootstrapPortlet/ws/RELEASES/1.0.2/BootstrapPortletEAR.ear

          The _RELEASES_ folder __ is a symlink. So we basically use Jenkins as a file server just like Glenn.

           

          We do not use symlinks in the userContent folder, but we do use it in the job workspace.

          Show
          arjo_poldervaart Arjo Poldervaart added a comment - - edited Our use is similar to that of Glenn. To provide some context: If we want to release an artifact to production, we tag it in our SCM and let Jenkins build it, Jenkins then copies the artifact to a different location so we can download it at a later time (even if the workspace is cleared). The copy is done via a symlink created in the workspace by our build script (soft link on Linux) to a folder outside the workspace on disk. When we want to deploy the artifact we can simply download it via een link like: /view/assets/job/assets-BootstrapPortlet/ws/ RELEASES /1.0.2/BootstrapPortletEAR.ear The _ RELEASES _ folder __ is a symlink. So we basically use Jenkins as a file server just like Glenn.   We do not use symlinks in the userContent folder, but we do use it in the job workspace.
          Hide
          jthompson Jeff Thompson added a comment -

          Glenn Herbert and Arjo Poldervaart, thanks for your responses on describing your use models. That helps clarify some things.

          Have you read the security advisory from last year at https://jenkins.io/security/advisory/2018-12-05/ ? Have you tried disabling that fix via the system property described there? It sounds like your use cases are some of the rare situations where that might make sense.

          Show
          jthompson Jeff Thompson added a comment - Glenn Herbert and Arjo Poldervaart , thanks for your responses on describing your use models. That helps clarify some things. Have you read the security advisory from last year at  https://jenkins.io/security/advisory/2018-12-05/  ? Have you tried disabling that fix via the system property described there? It sounds like your use cases are some of the rare situations where that might make sense.
          Hide
          arjo_poldervaart Arjo Poldervaart added a comment -

          Hi Jeff,

          We have been running with "-Dhudson.model.DirectoryBrowserSupport.allowSymlinkEscape=true" for quite a while already. The setting does not resolve the current issue.

          Show
          arjo_poldervaart Arjo Poldervaart added a comment - Hi Jeff, We have been running with "-Dhudson.model.DirectoryBrowserSupport.allowSymlinkEscape=true" for quite a while already. The setting does not resolve the current issue.
          Hide
          kansasmann Glenn Herbert added a comment -

          Same here, been running with SymlinkEscape=true for quite a while.

          Show
          kansasmann Glenn Herbert added a comment - Same here, been running with SymlinkEscape=true for quite a while.
          Hide
          jthompson Jeff Thompson added a comment -

          I'm able to reproduce Matt's simple test case on Unix and Windows. Hopefully it's a reasonably good representation of the other problems people are experiencing. Looks like the `allowSymlinkEscape` property isn't working the way it was intended. I'll see if I can figure something out to make it work better. It may take a while to get that change put together.

          Show
          jthompson Jeff Thompson added a comment - I'm able to reproduce Matt's simple test case on Unix and Windows. Hopefully it's a reasonably good representation of the other problems people are experiencing. Looks like the `allowSymlinkEscape` property isn't working the way it was intended. I'll see if I can figure something out to make it work better. It may take a while to get that change put together.

            People

            • Assignee:
              Unassigned
              Reporter:
              kansasmann Glenn Herbert
            • Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated: