commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Bodewig (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COMPRESS-379) isUnixSymlink returns true for Zip entries with Unix permissions 177777
Date Sun, 15 Jan 2017 18:51:26 GMT

    [ https://issues.apache.org/jira/browse/COMPRESS-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15823219#comment-15823219
] 

Stefan Bodewig commented on COMPRESS-379:
-----------------------------------------

But the same would be true for all other things you do with the "unix mode". The flag that
indicates a symlink *is* set in your example.

If we follow the logic that an attribute of "all bits set" is invalid then we shouldn't change
the code here, but {{getUnixMode}} instead so that it returns 0 rather than {{SHORT_MASK}},
which in turn would remove all permissions as well. Why would we trust those more than the
symlink flag?

> isUnixSymlink returns true for Zip entries with Unix permissions 177777
> -----------------------------------------------------------------------
>
>                 Key: COMPRESS-379
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-379
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Archivers
>    Affects Versions: 1.13
>            Reporter: Guillaume Boué
>         Attachments: invalid-entry.jar
>
>
> This issue was originally reported in MASSEMBLY-842, but it seems the root cause in inside
Commons Compress.
> Consider the attached {{invalid-entry.jar}}, whose contents, as shown by the {{zipinfo}}
utility, is:
> {noformat}
> ?rwsrwsrwt  2.0 unx        0 b- stor 17-Jan-15 16:06 META-INF/maven/
> drwxr-xr-x  2.0 unx        0 b- stor 17-Jan-15 16:06 META-INF/
> {noformat}
> There are some JAR files created by the Maven Assembly Plugin with content similar to
this, and the entry {{META-INF/maven/}} has permissions 177777 (octal). Constructing a {{ZipFile}}
from this file, the method {{isUnixSymlink}} incorrectly returns {{true}} for the entry {{META-INF/maven/}}
(and it correctly returns {{false}} for the entry {{META-INF/}}.
> Here is a sample Java code that can be used to see the behaviour:
> {code:java}
> public static void main(String[] args) throws IOException {
>     try (ZipFile zipFile = new ZipFile(new File("invalid-entry.jar"))) {
>         printAttributes(zipFile, "META-INF/");
>         printAttributes(zipFile, "META-INF/maven/");
>     }
> }
> private static void printAttributes(ZipFile zipFile, String name) {
>     ZipArchiveEntry entry = zipFile.getEntriesInPhysicalOrder(name).iterator().next();
>     System.out.printf("%-17s: symlink:%-5s - unixMode:%s%n", name, entry.isUnixSymlink(),
entry.getUnixMode());
> }
> {code}
> This code outputs:
> {noformat}
> META-INF/        : symlink:false - unixMode:16877
> META-INF/maven/  : symlink:true  - unixMode:65535
> {noformat}
> The {{?rwsrwsrwt}} permissions show that the Zip entry is broken in the first place,
but I think {{isUnixSymlink}} should still return {{false}} in that case, and not consider
this entry to be a symlink.
> It seems the fix would be to update {{isUnixSymlink}} and check whether the unix mode
is equal to {{SHORT_MASK}}, and return {{false}} in that case as it would indicate a broken
entry. This change does not break any existing tests, but I'm not sure if this is the proper
fix.
> {code:java}
> public boolean isUnixSymlink() {
>     int unixMode = getUnixMode();
>     return unixMode == SHORT_MASK ? false : (unixMode & UnixStat.LINK_FLAG) == UnixStat.LINK_FLAG;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message