Re-iterate JDK-6194856: Zip Files lose ALL ownership and permissions of the files

[Xueming Shen]

It's hard to get the ZipEntry API right to perfectly handle these 
platform specific
"file system attributes" especially given the potential performance and 
security
concern.

I would assume zipfs might be a better place to handle this if "really" 
desired,
in which already has the base to handle "file attributes". We can have a 
zipfs
based jar/zip somewhere to take advantage of its file system nature. For
example, start from "open/test/jdk/jdk/nio/zipfs/Demo.java" :-)

-Sherman


On 9/12/18, 9:18 AM, Martin Buchholz wrote:
> In principle I support making system specific extensions to the ZIP
> spec more supported, as other zip implementations do.  There is long
> standing tension between Java trying to be highly portable and
> providing access to the data you need.  It's already the case that
> some implementation bits are not exposed but the zip implementation
> handles it "magically" under the covers, e.g. IIRC the utf-8 bit.
> There is also tension between ZipEntry as just a mutable struct and a
> read-only interface to an existing zip file.  Performance of zip
> implementations is critical so one would like to do lazy lookup.
> Coming up with a good design for j.u.zip evolution is hard.
>
> On Wed, Sep 12, 2018 at 7:44 AM, Langer, Christoph
> <christoph.langer at sap.com>  wrote:
>> Hi all,
>>
>> I'm currently revisiting a long standing shortcoming of the java.util.zip (and java.util.jar) implementation.
>>
>> The lack is that in the current implementation, Unix mode bits (e.g. rwx) are not stored/read from zip or jar files and the jar tool has no capabilities to store/preserve the mode information. There have been several bugs opened but they were closed with "Won't Fix". One of them is JDK-6194856, mentioned in this mail's subject [1]. Unfortunately there is no detailed reasoning given why that can't be done. Maybe these are compatibility or security issues? Maybe someone can enlighten me about previous discussions concerning this matter...
>>
>> I personally can imagine contributing the following:
>>
>> First step: Enrich java.util.zip.ZipEntry with some method(s) like getUnixPermissions() and setUnixPermissions().
>> For writing zip files it would mean depending on the availability of Unix permission information in a ZipEntry object, the entry version would be set to "3 - Unix" according to section "D.  Explanation of fields", "version made by (2 bytes)" of the zip specification that is referenced in the current Javadoc for the java.util.zip package [2].
>> Reading Zip files would take into account the file attribute mapping of the version field and in case of "3 - Unix", it would read the permissions settings from the external file attributes section of the entry header.
>> This seems to be the de-facto standard of the GNU zip/unzip implementation.
>> With that addition the the java.util.zip API, developers using it would get the ability to cope with Unix permissions.
>>
>> As a second step, I can imagine spending a flag for the jar utility to have it handle Unix permissions when packing/extracting.
>>
>> Isn't that something that should be done? Or, if not, why?
>>
>> Thanks and best regards in advance
>> Christoph
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-6194856
>> [2] http://www.info-zip.org/doc/appnote-19970311-iz.zip
>>