RFR[8230946]: Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

[Patrick Concannon]

Hi,


I've updated the fix for JDK-8230946 
<https://bugs.openjdk.java.net/browse/JDK-8230946>with the feedback 
received here and from the CSR (JDK-8231305 
<https://bugs.openjdk.java.net/browse/JDK-8231305>). The new webrev can 
be found below:
http://cr.openjdk.java.net/~pconcannon/8230946/webrevs/webrev.04/


Kind regards,

Patrick

On 30/09/2019 16:45, Chris Hegarty wrote:
>
> On 30/09/2019 15:27, Alan Bateman wrote:
>> On 30/09/2019 15:10, Patrick Concannon wrote:
>>> Hi Alan,
>>>
>>>
>>> A new issue has been created as requested, and can be found here: 
>>> https://bugs.openjdk.java.net/browse/JDK-8231570
>> In JDK-8231570, I think Chris is concerned that a custom SM will 
>> observe, and may prevent, send/receive from binding where as an 
>> implicit bind by connect is not observed by the SM. It will not be 
>> wrong for the binding in connect to go through the SM too.
>
> One could reasonably write a test that connects an unbound channel, 
> and expect that SM::checkListen is invoked.
>
> My intention was to use 8231570, in part, to examine the` @throws 
> SecurityException` for receive. ( as well as what was mentioned above )
>
>
>> The related issue that we touched on here is that 
>> DatagramChannel.receive does not specify that it discards datagrams 
>> when denied by the SM. I think we will need to adjust the wording for 
>> the SecurityException.
>
> DatagramChannel::receive has the following @throws:
>
>      * @throws  SecurityException
>      *          If a security manager has been installed
>      *          and it does not permit datagrams to be accepted
>      *          from the datagram's sender
>
> This is incorrect.
>
> The specification should say that denied datagram packets will be 
> discarded **.
>
> The only possible "fix" here, ignoring implicit bind since that will 
> be handled by 8231570, is to remove the @throws ( as well as adding 
> some spec verbiage, which is already implicit through the link to 
> DatagramSocket ). But it might be prudent to not remove @throws yet, 
> given 8231570 is still unresolved. 8231570 can be used to "fix" the 
> @throws, to either 1) remove it, or 2) modify it to say that the bind 
> may throw.
>
> I don't have a strong opinion either way which JIRA issue is used for 
> which parts of the change, just that the changes happen without 
> removing and re-adding an @throws
>
> -Chris.
>
> ** If registered with a selector for OP_READ, after waking up that 
> selector then discarding the datagram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20191002/7145be81/attachment-0001.html>