RFR (Enhancement): 6194856: Zip Files lose ALL ownership and permissions of the files

[Alan Bateman]

On 25/09/2018 15:57, Langer, Christoph wrote:
>
> Hi all,
>
> I had asked for opinions regarding adding posix permission support to 
> JDK’s zip handling libraries and tools [1]. Since I didn’t get clear 
> “no, you can’t do this” answers, I’m now concretely proposing some 
> enhancements in the area of java.util.zip, jdk.zipfs and jdk.jartool.
>
> I have reopened the long standing bug report (6194856) which had been 
> set to “Won’t fix” quite recently for this purpose.
>
> Here are the technical details:
>
> The ZIP format specifications by infozip and pkware ([2] and [3]) do 
> not explicitly specify the handling of posix file permissions. But it 
> seems to be common sense that if file attribute compatibility is set 
> to “Unix” in the upper byte of CEN field “version made by”, the file 
> permissions bits are stored in CEN field “external file attributes”, 
> byte 3 and 4. My changes try to honor this in the least obtrusive way. ��
>
> The following changes are proposed:
>
> java.util.zip.ZipEntry:
>
> it will have an additional field “posixPerms”. A value of -1 means “no 
> permission information”, positive values will contain the flag values.
>
> There will be 2 new public methods to read/set the permission information:
>
>                 public Optional<Set<PosixFilePermission>> 
> getPosixPermissions()
>
>                 public void 
> setPosixPermissions(Set<PosixFilePermission> permissions)
>
> The usage of type “Optional” reflects that posix permissions are not 
> necessarily present in a zip file
>
> java.util.zip.ZipFile:
>
>                 it will have the capability to read the CEN fields and 
> set posixPerms if available
>
> java.util.zip.ZipOutputStream:
>
>                 it will store entries with associated posix 
> permissions as unix type in the CEN, together with the bit mask for 
> the permissions
>
> jdk.jartool:
>
> I propose to add and option "--preserve-posix" or short "-o" to honor 
> the posix bits that may be stored inside zip/jar files. By default the 
> option is not set and hence posix permissions are ignored. If the flag 
> is set and the file system that the jar tool is running on supports 
> posix, posix file permissions that exist in the file system will be 
> stored in newly created/update archives or restored to the file system 
> if such information is present in the archive.
>
> jdk.zipfs:
>
>                 I added the capability for posix file permissions in 
> the implementation. I decided to support PosixFileAttributes by 
> subclassing ZipFileAttributes from this superclass as well as 
> subclassing ZipFileAttributeView from PosixFileAttributeView. However, 
> as PosixFileAttributes also include groups and owners, I would throw 
> UnsupportedOperationExceptions in case of invoking methods to handle 
> these attributes. But this approach seems to be most consistent with 
> e.g. Files.setPosixFilePermissions and Files.getPosixFilePermissions.
>
> java.nio.file.attribute.PosixFilePermissions:
>
>                 As this class presents a collection of static helpers, 
> I added definitions for the posix file bit masks together with methods 
> to convert between Sets of PosixFilePermission to bit masks containing 
> the according switches and vice versa. These definitions could 
> theoretically also be moved inside the java.util.zip or jdk.zipfs 
> implementations where they wouldn’t be exposed as public APIs. 
> However, in that case the code would probably need to be duplicated.
>
> I’ve also created two jtreg testcases for both, java.util.zip and 
> jdk.nio.zipfs.
>
> The changes also contain a few further code cleanups.
>
> Here are the links:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-6194856 
> <https://bugs.openjdk.java.net/browse/JDK-6194856>
>
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/6194856.0/ 
> <http://cr.openjdk.java.net/%7Eclanger/webrevs/6194856.0/>
>
> I’ll write a CSR once there’s some substantial feedback to my endeavor.
>
>
I think this will require significant discussion as it was previously 
closed as WNF (as you found).

One initial comment is that you should be able to drop the API additions 
to PosxFilePermissions - I think all you need there translation from 
Set<PosixFilePermission> to internal values, it doesn't require bloating 
the API.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180925/e0dc7adc/attachment-0001.html>