Maven 2.x Assembly Plugin

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

duplicates

Bug - A problem which impairs or prevents the functions of the product. MASSEMBLY-422 Generated directories have wrong file attributes

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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.

People

  • Assignee:
    Unassigned
    Reporter:
    James Kavanagh
Vote (14)
Watch (11)

Dates

  • Created:
    Updated:
    Resolved: