<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hi Lance,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">I was not aware of
</span><span lang="EN-US">JDK-8182117 and by its description it does not fit exactly to the updates to jdk.zipfs module documentation that I propose. However, yes, it is probably a bit more natural to include that part in a potential patch for JDK-8182117.
So, feel free to take this over into your work. Seeing how things are going with this POSIX permission topic, I’m sure you’ll be done with a patch for 8182117 much earlier than me
</span><span lang="EN-US" style="font-family:"Segoe UI Emoji",sans-serif">😉</span><span lang="EN-US">.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Best<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Christoph</span><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Lance Andersen <lance.andersen@oracle.com>
<br>
<b>Sent:</b> Samstag, 12. Januar 2019 15:01<br>
<b>To:</b> Langer, Christoph <christoph.langer@sap.com><br>
<b>Cc:</b> Alan Bateman <Alan.Bateman@oracle.com>; nio-dev <nio-dev@openjdk.java.net>; OpenJDK Dev list <security-dev@openjdk.java.net>; Java Core Libs <core-libs-dev@openjdk.java.net><br>
<b>Subject:</b> Re: RFR 8213031: (zipfs) Add support for POSIX file permissions<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi Christoph<o:p></o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Jan 12, 2019, at 8:02 AM, Langer, Christoph <<a href="mailto:christoph.langer@sap.com">christoph.langer@sap.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Hi Alan,<br>
<br>
as I did not hear back from you I continued to work on the POSIX file permission support for zipfs and specified/implemented the value of 'null' for zip entries with no permission information associated (vs. UnsupportedOperationException).<br>
<br>
I updated the CSR: <a href="https://bugs.openjdk.java.net/browse/JDK-8213082">https://bugs.openjdk.java.net/browse/JDK-8213082</a><br>
And here is an updated webrev for the change: <a href="http://cr.openjdk.java.net/~clanger/webrevs/8213031.5/">
http://cr.openjdk.java.net/~clanger/webrevs/8213031.5/</a><br>
<br>
I also changed the first part of the module-info documentation for jdk.zipfs, mentioning the URI scheme 'jar' and corrected the information about how the zip file system provider can be accessed and new zip filesystems can be<o:p></o:p></p>
</div>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">created.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">I think the above should be addressed via JDK-8182117 which I will be addressing and keep this focused on the POSIX file permission enhancements as I think it should be in its own CSR.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Best<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Lance<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><br>
Please kindly review this.<br>
<br>
Thank you and best regards<br>
Christoph<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">-----Original Message-----<br>
From: Langer, Christoph<br>
Sent: Dienstag, 8. Januar 2019 09:27<br>
To: 'Alan Bateman' <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>>; Volker Simonis<br>
<<a href="mailto:volker.simonis@gmail.com">volker.simonis@gmail.com</a>><br>
Cc: nio-dev <<a href="mailto:nio-dev@openjdk.java.net">nio-dev@openjdk.java.net</a>>; OpenJDK Dev list <security-<br>
<a href="mailto:dev@openjdk.java.net">dev@openjdk.java.net</a>>; Java Core Libs <<a href="mailto:core-libs-dev@openjdk.java.net">core-libs-dev@openjdk.java.net</a>><br>
Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions<br>
<br>
Hi Alan, Volker,<br>
<br>
thanks for bringing up these discussion points. I agree that we shall carefully<br>
revisit that.<br>
<br>
First of all, I'd like to point out that PosixFileAttributeView::readAttributes<br>
won't ever throw UOE with the proposed changes to zipfs. It should always<br>
return an object of type PosixFileAttributes which will be an incarnation of<br>
ZipFileSystem.Entry.<br>
<br>
The returned PosixFileAttributes(ZipFileSystem.Entry) object now<br>
implements 3 additional methods: owner(), group() and permissions(). I can<br>
see that UOE should only be thrown if something is not supported by an<br>
implementation at all. So it perfectly fits to owner() and group() because this<br>
is simply not implemented in zipfs (yet...). As for permissions, I then agree,<br>
UOE probably isn't the right thing to do because permissions will now be<br>
supported by zipfs.<br>
Still, we need to distinguish between the case where no permission<br>
information is present vs. an empty set of permissions that was explicitly<br>
stored. You brought up IOException as an alternative. But I think this is not<br>
really feasible for the following main reason: IOE is no RuntimeException, so<br>
it has to be declared for a method when it is thrown.<br>
PosixFileAttributes::permissions, however, does not declare IOE so far. And I<br>
don't think we can/want to modify the PosixFileAttributes interface for the<br>
sake of that zipfs implementation change.<br>
<br>
I think, we should look into using/returning null for "no permission<br>
information present".<br>
<br>
With that, the point is: What happens if we pass null to another<br>
PosixFileAttributeView::setPermissions implementation (or to<br>
Files::setPosixFilePermissions, which ends up there). For zipfs, with the<br>
proposed changeset, this would work perfectly fine. We translate the null<br>
value into (int)-1 for the "posixPerms" field of "Entry" and will then not set<br>
permission information in the zip file. But other places in the JDK that<br>
implement PosixFileAttributeView need some rework. Those are:<br>
src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.Posix<br>
src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.PosixFile<br>
AttributeViewImpl<br>
<br>
And we should amend the specs/doc for the following methods to define<br>
the handling of the null value as a noop:<br>
PosixFileAttributeView::setPermissions<br>
PosixFileAttributes::permissions<br>
Files::setPosixFilePermissions<br>
Files::getPosixFilePermissions<br>
<br>
In the implementation I can see that we modify the aforementioned places<br>
to handle null by translating it to (int)-1 in<br>
UnixFileModeAttribute::toUnixMode and then using this value as noop in<br>
'setMode' resp. 'fchmod'.<br>
<br>
Do you think this is the right way to go? Should we maybe do the spec<br>
update of the permission methods in a separate change?<br>
<br>
Best regards<br>
Christoph<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">-----Original Message-----<br>
From: Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>><br>
Sent: Montag, 7. Januar 2019 21:46<br>
To: Volker Simonis <<a href="mailto:volker.simonis@gmail.com">volker.simonis@gmail.com</a>><br>
Cc: Langer, Christoph <<a href="mailto:christoph.langer@sap.com">christoph.langer@sap.com</a>>; nio-dev <nio-<br>
<a href="mailto:dev@openjdk.java.net">dev@openjdk.java.net</a>>; OpenJDK Dev list <security-<br>
<a href="mailto:dev@openjdk.java.net">dev@openjdk.java.net</a>>; Java Core Libs <<a href="mailto:core-libs-dev@openjdk.java.net">core-libs-dev@openjdk.java.net</a>><br>
Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions<br>
<br>
On 07/01/2019 19:26, Volker Simonis wrote:<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="margin-bottom:12.0pt">:<br>
We considered this, but it is problematic because it is perfectly<br>
valid to have a file with external file attributes where none of the<br>
Posix attributes is actually set (i.e. an empty set of Posix files<br>
attributes). This wouldn't be distinguishable from the case where a<br>
file has no external file attributes. So it seems we have to resort to<br>
throwing an IOE?<o:p></o:p></p>
</blockquote>
<p class="MsoNormal">Maybe although it would be a bit awkward to deal with. The issues around<br>
this remind me a bit about mounting fat32 file systems on Linux or Unix<br>
systems where the fields in the stat structure are populated with<br>
default values. PosixFileAttributeView::readAttributes is essentially<br>
the equivalent of a stat call. This might be something to look at for<br>
the file owner at least.<br>
<br>
-Alan<o:p></o:p></p>
</blockquote>
</blockquote>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span class="apple-style-span"><span style="font-size:12.0pt;font-family:"Verdana",sans-serif;color:#666666"><a href="http://oracle.com/us/design/oracle-email-sig-198324.gif"><span style="text-decoration:none"><img border="0" width="114" height="26" style="width:1.1875in;height:.2708in" id="_x0030_8334E64-6053-48B8-B813-F869B5F6E8B8" src="cid:image001.gif@01D4ABE5.198BA670"></span></a></span></span><span class="apple-style-span"><span style="font-size:12.0pt;font-family:"Verdana",sans-serif;color:#666666"><o:p></o:p></span></span></p>
<div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Helvetica",sans-serif;color:black"><a href="http://oracle.com/us/design/oracle-email-sig-198324.gif"><br>
</a></span><span style="font-size:12.0pt;font-family:"Verdana",sans-serif;color:#666666">Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037<br>
</span><span style="font-size:12.0pt;font-family:"Verdana",sans-serif;color:red">Oracle</span><span style="font-size:12.0pt;font-family:"Verdana",sans-serif;color:#666666"> Java Engineering <br>
1 Network Drive <br>
Burlington, MA 01803<br>
</span><span style="font-size:13.5pt;font-family:"Helvetica",sans-serif;color:black"><a href="mailto:Lance.Andersen@oracle.com"><span style="font-size:12.0pt;font-family:"Verdana",sans-serif">Lance.Andersen@oracle.com</span></a></span><span style="font-size:13.5pt;font-family:"Helvetica",sans-serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica",sans-serif;color:black"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Verdana",sans-serif;color:#666666"><br>
<br>
</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>