JDK-8247499 : Have jarsigner preserve posix permission attributes
  • Type: CSR
  • Component: security-libs
  • Sub-Component: java.security
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 8-pool,11-pool,16
  • Submitted: 2020-06-12
  • Updated: 2020-07-03
  • Resolved: 2020-07-02
Related Reports
CSR :  

Have the jarsigner tool retain POSIX permission attributes already in place during signing operations.

Following on from work already done via https://bugs.openjdk.java.net/browse/JDK-8213082:

POSIX file systems define a certain set of permission attributes for files (e.g. read, write, execute for user, group or all). Being able to store POSIX permission information in Zip files is an important requirement that users of Zip files are in need of on POSIX systems.

Although there is no explicit definition in the Zip specification about the canonical way to store these attributes, there exists a common sense amongst implementors of Zip tooling serving as a de-facto standard, leveraging Zip's CEN header fields version made by and external file attributes. Support for POSIX Permissions is based on the work in info-zip implementation which is available as open source: http://infozip.sourceforge.net/

When jarsigner is used to sign a jar/zip file, a new zip is cloned and replaces the original file once signed. Until this enhancement, jarsigner ignores such POSIX permission file attributes stored in the file being signed and resets them to '0' in the newly signed file. Files created from the jar tool don't store POSIX permission attribute values. The issue mainly affects files created by the zip tool implementation. The info-zip project provides a zipinfo command and the JDK Zip FS has support for displaying such attributes (e.g. java jdk.nio.zipfs.ZipInfo foo.zip).


Make jarsigner POSIX permission attributes aware. If such attributes are present in a file being signed, preserve them. 

A new warning will also be emitted from the jarsigner tool when signing and verifying signed files that contain POSIX permission attributes. The warning will indicate that such attribute values are not used during the file verification process. The warning printed will be: "POSIX permission attributes detected. Note that these attributes are unsigned and not protected by the signature."


A JDK implementation specific behavioural change to have jarsigner preserve POSIX file permissions, when present. POSIX permission attributes stored with any entry in the original jar/zip resource will be saved in the newly signed jar/zip file.

[~alanb] is correct in my intentions -- I was asking if there are additional attributes that should receive analogous treatment in follow-up work.

I think `jarsigner` should preserve, by default, all meta data to avoid surprises. There may be work beyond this issue to ensure this is the case. So I think Joe's suggestion is for follow-on issues.

Moving amended request to Approved. Looking for the referenced zip docs, are there are other useful "extra" attributes that it would be helpful to treat similarly (preserve, warn if not included in the signature computation, etc.)?

ACK, there are a few topics that may require discussion, in particular there may be an argument that `jarsigner` should copy file permissions by default (from the user's perspective, the tool signs a JAR file so surprising/annoying if it drops meta data). As the signing doesn't cover the meta data then emitting a warning seems right. I think `-verfiy` option also needs to print a warning a signed entry has file permissions.

I've asked [~alanb] for his input on this request; marking as pended until he gets back.