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

Permissions on directories in a zipped archive incorrect

    Details

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

      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

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          1090d 21h 8m 1 Dennis Lundberg 07/Nov/12 07:05
          Mark Thomas made changes -
          Workflow jira [ 12954611 ] Default workflow, editable Closed status [ 12991975 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 22:33:31 UTC 2015 [ 1428273211083 ]
          Mark Thomas made changes -
          Workflow jira [ 12717396 ] Default workflow, editable Closed status [ 12760674 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 09:09:00 UTC 2015 [ 1428224940639 ]
          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.
          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.
          Dennis Lundberg made changes -
          Resolution Fixed [ 1 ]
          Fix Version/s 2.4 [ 18308 ]
          Status Open [ 1 ] Closed [ 6 ]
          Dennis Lundberg made changes -
          Component/s permissions [ 15769 ]
          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.
          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 -

          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
          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
          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 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.
          Andreas Veithen made changes -
          Field Original Value New Value
          Link This issue duplicates MASSEMBLY-422 [ MASSEMBLY-422 ]
          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.
          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
          Michael 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
          Michael 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
          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.
          James Kavanagh created issue -

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development