JDK-8213031 : (zipfs) Add support for POSIX file permissions
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.nio
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-10-26
  • Updated: 2023-10-17
  • Resolved: 2019-08-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 14
14 b09Fixed
Related Reports
CSR :  
JDK-8213082 - (zipfs) Add support for POSIX file permissions
Duplicate :  
JDK-6194856 - Zip Files lose ALL ownership and permissions of the files
Relates :  
JDK-8287162 - (zipfs) Performance regression related to support for POSIX file permissions
Relates :  
JDK-6194856 - Zip Files lose ALL ownership and permissions of the files
Relates :  
JDK-8222276 - (zipfs) Refactoring and cleanups to prepare for JDK-8213031
Relates :  
JDK-8273935 - (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported
Description
It seems to be a de-facto standard that zip tools on Unix/Posix platforms support Posix file permissions in zip archives by storing them in the external attributes field in zip's CEN header. This can be seen in the Infozip implementation for instance. The Java JDK shall also honor this in its zip file system implementation.
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/bf325b739c8a User: clanger Date: 2019-08-07 10:33:02 +0000
07-08-2019
Enhancement request declined by Project Lead. I’m declining this request because it’s a nontrivial change that’s not critical to the success of the release and, more importantly, because it may impact the performance of javac, which uses the Zip filesystem. RDP 1 is not the time to be finding, debugging, and fixing such issues. Please retarget to JDK 14, in which there will be plenty of time to shake out this change.
21-06-2019
I don't have any objection to this feature going into JDK 13 during RDP1. Most of the feature requires opt-in when creating a zip file system, the only default behavior is to support the "zip:permissions" attribute. It would be nice if the microbenchmarks suite had tests for zipfs that cover the performance critical code paths that javac uses - this is only because javac is the most important user of the zip file system to scan the class path and the entries in JAR files.
17-06-2019
A reminder to submit CSRs ahead of JDK 13 rampdown 1 was sent on May 22, 2019 (https://mail.openjdk.java.net/pipermail/jdk-dev/2019-May/002976.html). The CSR for this change was finalized on June 5, 2019 and changed to indicate it was targeting JDK 13 on June 7, 2019. The CSR was approved on June 14, 2019, which is in line with the nominal one week review SLA after all the necessary information was in the CSR. Several dozen other CSRs were reviewed in the two weeks before JDK 13 rampdown. Engineers are responsible to budget sufficient time for CSR review, which includes time to respond to possible feedback (https://wiki.openjdk.java.net/display/csr/CSR+FAQs).
17-06-2019
Late Enhancement Request Requesting this enhancement for JDK13. The risk should be low to medium, because the main part of the change is added functionality for the zipfs filesystem provider that is not enabled by default. There is some change in the common code path, though, that'll read posix file attribute information, though. However, should larger regressions be discovered during rdp testing, the change could probably be backed out easily. The main reason for requesting the RDP1 enhancement is that the technical work is mostly complete now. Unfortunately it took a bit too long to get CSR review which only came a few hours after JDK13 RDP1 cutoff. The code review is nearly done now, expecting the final ok this week. The patch itself runs through SAP's test system every night without showing regressions. Time estimate to get this work pushed is ~1 week (06/24).
17-06-2019
I agree that effectively, in POSIX file systems, the file permissions go together with the according principals. However, the set of permissions for files is some valuable information in itself, even without knowing the original principals. E.g. it might be necessary to distinguish at file creation time if a certain file needs the executable bit set or not. And that's what is transported in zip files. I think this point can be addressed in the documentation.
31-10-2018
One concern is that all "POSIX File Permissions" are specifically linked with a particular "principal", but the proposed change here is only to provide the support for the "permission" without corresponding support for the "principal", in which it passes the responsibility to the customer of this "feature" to assume/guess/interpret the role of "group", "owner" and "other", and with the potential risk that the resulting principals are probably not the same principals of the original permissions.
31-10-2018
Please mail security-dev. Support for POSIX file permissions has been looked at several times over the years but there are significant security concerns that need discussion, mostly related to java.util.zip and the jar tool.
27-10-2018
Hi Alan, what do you mean by security review? Shall I post it on security-dev and wait for a review from that end? Or is there some other Oracle process that I'm not aware of? Thanks Christoph
26-10-2018
This will require security review. If it goes ahead then it will also need a CSR as it exports new attributes as a supported interface.
26-10-2018