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

unzip step doesn't set permissions on extracted files

    XMLWordPrintable

Details

    Description

      Run this pipeline:

      node() {
          // create an example ZIP file
          sh '''\
              base64 -d > test.zip << EOF
              UEsDBAoAAAAAAJ2SrkwAAAAAAAAAAAAAAAAIABwAdGVzdC5iaW5VVAkAA1qp+VpaqfladXgLAAEE
              6AMAAAToAwAAUEsBAh4DCgAAAAAAnZKuTAAAAAAAAAAAAAAAAAgAGAAAAAAAAAAAAP2BAAAAAHRl
              c3QuYmluVVQFAANaqfladXgLAAEE6AMAAAToAwAAUEsFBgAAAAABAAEATgAAAEIAAAAAAA==
              EOF'''.stripIndent()
          sh 'unzip -o test.zip && ls -l test.bin && rm test.bin'
          unzip zipFile: 'test.zip', quiet: true
          sh 'ls -l test.bin'
      }
      

      The (relevant) output is:

      + ls -l test.bin
      -rwxrwxr-x 1 jenkins jenkins 0 May 14 15:20 test.bin
      ...
      + ls -l test.bin
      -rw-r--r-- 1 jenkins jenkins 0 May 14 15:51 test.bin
      

      You can see that the native unzip program extracts the file with the permissions it actually has in the archive (775), while the unzip step extracts it with default permissions (644).

      Attachments

        Issue Links

          Activity

            I looked at how the zip and unzip steps are implemented.

            The unzip step copies the file content as a stream and does not attempt to set the file modes, so this is clearly a missing feature there.

            In contrast, the zip step calls ArchiverFactory.ZIP.create and then Archiver.visit, i.e. ZipArchiver.visit, which attempts to save the file mode:

            If the zip step loses the permissions regardless, then the problem might be caused by JENKINS-53874, in which case it should be fixed in the Jenkins core. (The "version made by" and "external file attributes" fields described in APPNOTE.TXT - .ZIP File Format Specification are relevant. JENKINS-64818 is similar but not the cause here, because it applies to VirtualFile.zip rather than ZipArchiver.)

            kon Kalle Niemitalo added a comment - I looked at how the zip and unzip steps are implemented. The unzip step copies the file content as a stream and does not attempt to set the file modes, so this is clearly a missing feature there. UnZipFileCallable.invoke calls FilePath.write and then IOUtils.copy In contrast, the zip step calls ArchiverFactory.ZIP.create and then Archiver.visit, i.e. ZipArchiver.visit, which attempts to save the file mode: ZipItFileCallable.invoke calls Archiver.visit ZipArchiver.visit calls ZipEntry.setUnixMode If the zip step loses the permissions regardless, then the problem might be caused by JENKINS-53874 , in which case it should be fixed in the Jenkins core. (The "version made by" and "external file attributes" fields described in APPNOTE.TXT - .ZIP File Format Specification are relevant. JENKINS-64818 is similar but not the cause here, because it applies to VirtualFile.zip rather than ZipArchiver.)

            I changed the status from In Progress back to Open, because the user who started the progress is no longer active and I didn't find any related pull request.

            kon Kalle Niemitalo added a comment - I changed the status from In Progress back to Open, because the user who started the progress is no longer active and I didn't find any related pull request.
            hamaney aby abo added a comment -

            I am having the same issue using the built-in zip function

            hamaney aby abo added a comment - I am having the same issue using the built-in zip function

            Complementary to this, the zip step does not appear to preserve file permissions in the created archive.

            rsandell, is it fair to assume that both of these issues would be addressed at the same time?

            braden Braden McDaniel added a comment - Complementary to this, the zip step does not appear to preserve file permissions in the created archive. rsandell , is it fair to assume that both of these issues would be addressed at the same time?

            People

              rsandell rsandell
              rdonchen_intel Roman Donchenko
              Votes:
              5 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated: