RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue

[Baesken, Matthias]

Hi Alan, Goetz,

>There are several issues with this proposal. The security concern is the main one and I think we should wait for comment from security-dev.
  .....

>If this is required, I would choose a more generic tag

>so it can be reused in other places.

>I would just use "path".

>

>Best regards,

>  Goetz.

Thanks for  the comments .   Sure,  I can use path  for the category naming  as well, but would be good to hear the  opinions of  the security-dev guys on this .

> The second concern is that the patch is incomplete and inconsistent in that it changes the exception throw by two methods,
>it ignores other file I/O methods that throw exceptions.

We  have these extended exceptions for quite some time in our JVM;   we decided to   enhance exceptions where we have a path already "at hand" ,
  so it was easy to extend the exceptions .
In case you think this can be done with some others , that's fine with me -  do you have some concrete examples ?

A lot of IO exceptions currently thrown that use JNU_ThrowIOExceptionWithLastError  do not have a path (at least not where the exception is thrown).


Best regards ,
                Matthias



From: Alan Bateman <Alan.Bateman at oracle.com>
Sent: Freitag, 12. Oktober 2018 11:18
To: Baesken, Matthias <matthias.baesken at sap.com>; security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue

On 12/10/2018 09:12, Baesken, Matthias wrote:

Ping ...  any reviews / comments ?

Should I add  a category  , for example    "ioExceptionsWithPath"     to the java.security - file  to control  the enabling/disabling of the  enhanced exception ?

  java.security

#
# Enhanced exception message information
...
#jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath

There are several issues with this proposal. The security concern is the main one and I think we should wait for comment from security-dev. The second concern is that the patch is incomplete and inconsistent in that it changes the exception throw by two methods, it ignores other file I/O methods that throw exceptions. Finally there is the concerns with the patch itself that both Roger and I commented on.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20181012/3ffae8e8/attachment.htm>