Maven Assembly Plugin
  1. Maven Assembly Plugin
  2. MASSEMBLY-449

Permissions on directories in a zipped archive incorrect

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2-beta-4
    • Fix Version/s: 2.4
    • Component/s: permissions
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Using the following assembly plugin:

      <assembly>
          <id>target-packaged</id>
          <formats>
              <format>zip</format>
          </formats>
          <includeBaseDirectory>false</includeBaseDirectory>
          <moduleSets>
              <moduleSet>
                  <includes>
                      <include>*:core-env</include>
                  </includes>
                  <binaries>
                      <attachmentClassifier>env</attachmentClassifier>
                      <includeDependencies>false</includeDependencies>
                      <unpack>true</unpack>
                  </binaries>
              </moduleSet>
              <moduleSet>
                  <includes>
                      <include>*:data-bridge</include>
                  </includes>
                  <binaries>
                      <attachmentClassifier>target</attachmentClassifier>
                      <includeDependencies>false</includeDependencies>
                      <unpack>true</unpack>
                  </binaries>
              </moduleSet>
              <moduleSet>
                  <includes>
                      <include>*:web</include>
                  </includes>
                  <binaries>
                      <attachmentClassifier>web</attachmentClassifier>
                      <includeDependencies>false</includeDependencies>
                      <unpack>true</unpack>
                  </binaries>
              </moduleSet>
          </moduleSets>
      </assembly>
      

      When unzipping the result on a Linux host all the directory permissions have been set to 777.
      If I revert the plugin version to 2.2-beta-3 the issue goes away.

        Issue Links

          Activity

          Hide
          Max Bowsher added a comment -

          I confirm that the directory permission defaults have become excessively insecure in 2.2-beta-4, and that it happens with tar packaging as well as zip.

          Show
          Max Bowsher added a comment - I confirm that the directory permission defaults have become excessively insecure in 2.2-beta-4, and that it happens with tar packaging as well as zip.
          Hide
          Mike Power added a comment -

          I have also experienced this issue.

          It does not matter whether you set <directoryMode>

          I seem to be more successful at producing/preventing it by modifying the includes/excludes on a default fileset

          consider the file src/main/resources/somedir/somescript.sh and src/main/resources/somedir/sometext.txt
          //Good permissions
          <fileSets>
          <fileSet>
          <directory>$

          {basedir}/src/main/resources</directory>
          <fileMode>644</fileMode>
          <excludes>
          <exclude>*/.sh</exclude>
          </excludes>
          <outputDirectory></outputDirectory>
          </fileSet>
          <fileSet>
          <directory>${basedir}

          /src/main/resources</directory>
          <fileMode>755</fileMode>
          <lineEnding>unix</lineEnding>
          <includes>
          <include>*/.sh</include>
          </includes>
          <outputDirectory></outputDirectory>
          </fileSet>
          </fileSets>
          //Bad permissions
          <fileSets>
          <fileSet>
          <directory>$

          {basedir}/src/main/resources</directory>
          <fileMode>755</fileMode>
          <lineEnding>unix</lineEnding>
          <includes>
          <include>*/.sh</include>
          </includes>
          <outputDirectory></outputDirectory>
          </fileSet>
          <fileSet>
          <directory>${basedir}

          /src/main/resources</directory>
          <fileMode>644</fileMode>
          <excludes>
          <exclude>*/scripts/.*</exclude>
          <exclude>*/.sh</exclude>
          </excludes>
          <outputDirectory></outputDirectory>
          </fileSet>
          </fileSets>

          It seems like the includes/excludes patterns are applying to directories as well. In the first case the directory is by default included and it gets good permissions. In the second example the directory is excluded, but the somescript.sh file needs to go into the somedir directory. Thus somedir directory is created in response but with wide open permissions.

          I find I can usually handle this with fileSets by changing the order I do things. But for other items it becomes harder.

          Show
          Mike Power added a comment - I have also experienced this issue. It does not matter whether you set <directoryMode> I seem to be more successful at producing/preventing it by modifying the includes/excludes on a default fileset consider the file src/main/resources/somedir/somescript.sh and src/main/resources/somedir/sometext.txt //Good permissions <fileSets> <fileSet> <directory>$ {basedir}/src/main/resources</directory> <fileMode>644</fileMode> <excludes> <exclude>* / .sh</exclude> </excludes> <outputDirectory></outputDirectory> </fileSet> <fileSet> <directory>${basedir} /src/main/resources</directory> <fileMode>755</fileMode> <lineEnding>unix</lineEnding> <includes> <include>* / .sh</include> </includes> <outputDirectory></outputDirectory> </fileSet> </fileSets> //Bad permissions <fileSets> <fileSet> <directory>$ {basedir}/src/main/resources</directory> <fileMode>755</fileMode> <lineEnding>unix</lineEnding> <includes> <include>* / .sh</include> </includes> <outputDirectory></outputDirectory> </fileSet> <fileSet> <directory>${basedir} /src/main/resources</directory> <fileMode>644</fileMode> <excludes> <exclude>* /scripts/ .*</exclude> <exclude>* / .sh</exclude> </excludes> <outputDirectory></outputDirectory> </fileSet> </fileSets> It seems like the includes/excludes patterns are applying to directories as well. In the first case the directory is by default included and it gets good permissions. In the second example the directory is excluded, but the somescript.sh file needs to go into the somedir directory. Thus somedir directory is created in response but with wide open permissions. I find I can usually handle this with fileSets by changing the order I do things. But for other items it becomes harder.
          Hide
          Stefan Enev added a comment -

          This strange behavior happens on windows too. Some files with no permissions become read-only.
          We are using 2.2-beta5, reverting to 2.2-beta3 solved the problem.

          Show
          Stefan Enev added a comment - This strange behavior happens on windows too. Some files with no permissions become read-only. We are using 2.2-beta5, reverting to 2.2-beta3 solved the problem.
          Hide
          Klaus Reimer added a comment -

          Any news here? This bug is quite old and now I also stumbled over it when I tried to access the generated ZIP files with Midnight Commander. It gives me the error message "Inconsistent extfs archive". Midnight commander uses "unzip -Z" to get info about the ZIP. If I do this manually then I see broken directory permissions like this:

          ?rwsrwsrwt 2.0 unx 0 b- stor 10-Apr-11 15:41 ltray-1.0.0-SNAPSHOT/

          Plugin Version 2.2-beta3 generates ZIP files with these permissions (And they are correct and working):

          drwxr-xr-x 2.0 unx 0 b- stor 10-Apr-11 15:55 ltray-1.0.0-SNAPSHOT/

          So I reverted back to beta3, too, because I don't like it at all when Maven generates broken ZIP files.

          Show
          Klaus Reimer added a comment - Any news here? This bug is quite old and now I also stumbled over it when I tried to access the generated ZIP files with Midnight Commander. It gives me the error message "Inconsistent extfs archive". Midnight commander uses "unzip -Z" to get info about the ZIP. If I do this manually then I see broken directory permissions like this: ?rwsrwsrwt 2.0 unx 0 b- stor 10-Apr-11 15:41 ltray-1.0.0-SNAPSHOT/ Plugin Version 2.2-beta3 generates ZIP files with these permissions (And they are correct and working): drwxr-xr-x 2.0 unx 0 b- stor 10-Apr-11 15:55 ltray-1.0.0-SNAPSHOT/ So I reverted back to beta3, too, because I don't like it at all when Maven generates broken ZIP files.
          Andreas Veithen made changes -
          Field Original Value New Value
          Link This issue duplicates MASSEMBLY-422 [ MASSEMBLY-422 ]
          Hide
          Andreas Veithen added a comment -

          A workaround for this issue is to add the following configuration to the plugin:

           
          <configuration>
              <archiverConfig>
                  <fileMode>420</fileMode> <!-- 420(dec) = 644(oct) -->
                  <directoryMode>493</directoryMode> <!-- 493(dec) = 755(oct) -->
                  <defaultDirectoryMode>493</defaultDirectoryMode>
              </archiverConfig>
          </configuration>
          

          Tested with 2.2-beta-5.

          Show
          Andreas Veithen added a comment - A workaround for this issue is to add the following configuration to the plugin: <configuration> <archiverConfig> <fileMode>420</fileMode> <!-- 420(dec) = 644(oct) --> <directoryMode>493</directoryMode> <!-- 493(dec) = 755(oct) --> <defaultDirectoryMode>493</defaultDirectoryMode> </archiverConfig> </configuration> Tested with 2.2-beta-5.
          Hide
          Silvestrov Ilya added a comment -

          This problem still exist for 2.2.2 version.

          @Andreas, thanks for you workaround, it solves a problem.

          Show
          Silvestrov Ilya added a comment - This problem still exist for 2.2.2 version. @Andreas, thanks for you workaround, it solves a problem.
          Hide
          Andreas Kohn added a comment -

          I just spent some time trying to understand the octal/decimal issue here. From what I can see the difference between fileMode-inside-descriptor and fileMode-inside-pom seems to appear because the descriptor is parsed by the assembly plugin (see MASSEMBLY-173), while the pom <archiverConfig> is parsed using plexus's injection logic.

          In maven 2 the plexus IntConverter does not support octal/hexadecimal, while in maven 3 the equivalent code does (see https://github.com/sonatype/sisu/commit/badeded7ee09c3422265edd8d1b8172ee36b677d ). I've filed PLX-463 now to merge that change, but I guess the assembly-plugin would need changes as well then to depend on such a fixed plexus?

          Show
          Andreas Kohn added a comment - I just spent some time trying to understand the octal/decimal issue here. From what I can see the difference between fileMode-inside-descriptor and fileMode-inside-pom seems to appear because the descriptor is parsed by the assembly plugin (see MASSEMBLY-173 ), while the pom <archiverConfig> is parsed using plexus's injection logic. In maven 2 the plexus IntConverter does not support octal/hexadecimal, while in maven 3 the equivalent code does (see https://github.com/sonatype/sisu/commit/badeded7ee09c3422265edd8d1b8172ee36b677d ). I've filed PLX-463 now to merge that change, but I guess the assembly-plugin would need changes as well then to depend on such a fixed plexus?
          Hide
          Leo Leung added a comment -

          The workaround provided by Andreas Veithen no longer works with version 2.3 .
          I get the following exception when I try to add the <archiverConfig> configuration to get around this issue:

          [INFO] ------------------------------------------------------------------------
          [ERROR] FATAL ERROR
          [INFO] ------------------------------------------------------------------------
          [INFO] null
          [INFO] ------------------------------------------------------------------------
          [DEBUG] Trace
          java.lang.NullPointerException
                  at org.codehaus.plexus.components.io.attributes.PlexusIoResourceAttributeUtils.mergeAttributes(PlexusIoResourceAttributeUtils.java:70)
                  at org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResources(PlexusIoFileResourceCollection.java:149)
                  at org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:195)
                  at org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:455)
                  at org.apache.maven.plugin.assembly.filter.ComponentsXmlArchiverFileFilter.finalizeArchiveCreation(ComponentsXmlArchiverFileFilter.java:166)
                  at org.codehaus.plexus.archiver.AbstractArchiver.runArchiveFinalizers(AbstractArchiver.java:871)
                  at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:895)
                  at org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:512)
                  at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:185)
                  at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:452)
                  at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
                  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
                  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
                  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
                  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
                  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
                  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
                  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
                  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
                  at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
                  at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
                  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                  at java.lang.reflect.Method.invoke(Method.java:597)
                  at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
                  at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
                  at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
                  at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
          [INFO] ------------------------------------------------------------------------
          
          
          Show
          Leo Leung added a comment - The workaround provided by Andreas Veithen no longer works with version 2.3 . I get the following exception when I try to add the <archiverConfig> configuration to get around this issue: [INFO] ------------------------------------------------------------------------ [ERROR] FATAL ERROR [INFO] ------------------------------------------------------------------------ [INFO] null [INFO] ------------------------------------------------------------------------ [DEBUG] Trace java.lang.NullPointerException at org.codehaus.plexus.components.io.attributes.PlexusIoResourceAttributeUtils.mergeAttributes(PlexusIoResourceAttributeUtils.java:70) at org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.addResources(PlexusIoFileResourceCollection.java:149) at org.codehaus.plexus.components.io.resources.PlexusIoFileResourceCollection.getResources(PlexusIoFileResourceCollection.java:195) at org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:455) at org.apache.maven.plugin.assembly.filter.ComponentsXmlArchiverFileFilter.finalizeArchiveCreation(ComponentsXmlArchiverFileFilter.java:166) at org.codehaus.plexus.archiver.AbstractArchiver.runArchiveFinalizers(AbstractArchiver.java:871) at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:895) at org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:512) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:185) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:452) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] ------------------------------------------------------------------------
          Hide
          Kristian Rosenvold added a comment -

          @Leo Leung You need to update the plexus-io dependency of the assembly plugin to 2.0.3, which will arrive in maven central in a few hours

          Show
          Kristian Rosenvold added a comment - @Leo Leung You need to update the plexus-io dependency of the assembly plugin to 2.0.3, which will arrive in maven central in a few hours
          Hide
          Leo Leung added a comment -

          @Kristian Rosenvold Thanks for that. Overriding the dependency to plexus-io 2.0.3 worked.

          Show
          Leo Leung added a comment - @Kristian Rosenvold Thanks for that. Overriding the dependency to plexus-io 2.0.3 worked.
          Dennis Lundberg made changes -
          Component/s permissions [ 15769 ]
          Dennis Lundberg made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Fix Version/s 2.4 [ 18308 ]
          Resolution Fixed [ 1 ]
          Hide
          Julien Nicoulaud added a comment -

          I can still see this bug in 2.4. The workaround with the archiverConfig works.

          Show
          Julien Nicoulaud added a comment - I can still see this bug in 2.4. The workaround with the archiverConfig works.
          Hide
          Robert Metzger added a comment -

          I can confirm that the bug still exists with 2.4.

          Show
          Robert Metzger added a comment - I can confirm that the bug still exists with 2.4.

            People

            • Assignee:
              Unassigned
              Reporter:
              James Kavanagh
            • Votes:
              14 Vote for this issue
              Watchers:
              13 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: