Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8230946

Clarify security manager behaviour of a connected DatagramSocket and DatagramChannel

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      b18
    • Verification:
      Not verified

      Description

      The longstanding behavior of DatagramSocket::receive is that it does
      not perform a security manager check when connected ( which is similar
      to DatagramChannel ). The security manager check is performed during
      connect.

      The specification for DatagramSocket::receive incorrectly implies that
      the security manager check is always performed. Or at best, it is
      ambiguous about the connected behavior. From DatagramSocket::receive -

         * If there is a security manager, a packet cannot be received if the
         * security manager's {@code checkAccept} method does not allow it.

      DatagramSocket::receive should have wording similar to its NIO
      counterpart, DatagramChannel, e.g.

         * <p> This method performs exactly the same security checks as the {@link
         * java.net.DatagramSocket#receive receive} method of the {@link
         * java.net.DatagramSocket} class. That is, if the socket is not connected
         * to a specific remote address and a security manager has been installed
         * then for each datagram received this method verifies that the source's
         * address and port number are permitted by the security manager's {@link
         * java.lang.SecurityManager#checkAccept checkAccept} method. The overhead
         * of this security check can be avoided by first connecting the socket via
         * the {@link #connect connect} method.

      In fact, the discrepancy can be seen from the above two snippets. They
      somewhat contradict each other.

      ---

      A connected datagram socket /channel is a capability. It would be good
      if the API noted this.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              pconcannon Patrick Concannon
              Reporter:
              chegar Chris Hegarty
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: