Derby
  1. Derby
  2. DERBY-2883

template security policy file for network server uses undefined property derby.security.host

    Details

    • Urgency:
      Normal
    • Issue & fix info:
      Newcomer
    • Bug behavior facts:
      Security

      Description

      DERBY-2811 changed the use of

      permission java.net.SocketPermission "$

      {derby.drda.host}:*", "accept";

      to

      permission java.net.SocketPermission "${derby.security.host}:*", "accept";

      I think this is correct for the default policy file used by the network server, but incorrect for the user template file.

      I think rather than exposing this "internal property" derby.security.host, the template should continue to use ${derby.drda.host}

      and include comments about needing to change it if the server is listening on a wildcard address. Currently there's no explanation of where derby.security.host comes from.

        Activity

        Hide
        Kathey Marsden added a comment -

        Triage for 10.9. Mark as Newcomer. Good newcomer issue to learn a bit about java 2 security.

        Show
        Kathey Marsden added a comment - Triage for 10.9. Mark as Newcomer. Good newcomer issue to learn a bit about java 2 security.
        Hide
        Rick Hillegas added a comment -

        Triaged for 10.5.2: assigned normal urgency.

        Show
        Rick Hillegas added a comment - Triaged for 10.5.2: assigned normal urgency.
        Hide
        Daniel John Debrunner added a comment -

        I don't think setting the properties will work for two reasons:

        1) The template policy doesn't allow setting system properties. Most likely the user's policy file won't either.

        2) the server setting the properties will be too late, the policy file has already been processed by the time the Derby code will be running.

        Show
        Daniel John Debrunner added a comment - I don't think setting the properties will work for two reasons: 1) The template policy doesn't allow setting system properties. Most likely the user's policy file won't either. 2) the server setting the properties will be too late, the policy file has already been processed by the time the Derby code will be running.
        Hide
        Rick Hillegas added a comment -

        Right now the server bothers to set these properties only if the user forgets to install a security manager. I wonder if the server should always set these properties. This might reduce the number of errors which the customer can commit when fine-tuning the template policy. That might improve the out-of-box experience given the tendency of the Java security manager to swallow bad syntax silently and then cryptically fail. This affect the two properties you have mentioned: derby.security.host and derby.install.url. For derby.install.url, we should still beef up the comments in the policy file. This would be an argument for leaving these properties (appropriately renamed) in the template policy file.

        Off the top of my head, derby.__rt seems like a reasonable namespace for these properties. These properties conform to the definition in Property.java, which reserves this namespace for properties which are not persisted.

        I wonder also if the server should always set derby.system.home if it is not set. I think that this could, again, improve the out-of-box experience for customers who fine-tune the template policy.

        Show
        Rick Hillegas added a comment - Right now the server bothers to set these properties only if the user forgets to install a security manager. I wonder if the server should always set these properties. This might reduce the number of errors which the customer can commit when fine-tuning the template policy. That might improve the out-of-box experience given the tendency of the Java security manager to swallow bad syntax silently and then cryptically fail. This affect the two properties you have mentioned: derby.security.host and derby.install.url. For derby.install.url, we should still beef up the comments in the policy file. This would be an argument for leaving these properties (appropriately renamed) in the template policy file. Off the top of my head, derby.__rt seems like a reasonable namespace for these properties. These properties conform to the definition in Property.java, which reserves this namespace for properties which are not persisted. I wonder also if the server should always set derby.system.home if it is not set. I think that this could, again, improve the out-of-box experience for customers who fine-tune the template policy.
        Hide
        Daniel John Debrunner added a comment -

        Same issue with 'derby.install.url'.

        Both of these properties are marked as 'private to derby' in their javadoc, but yet there are exposed in the template file.

        I wonder if it would be clearer to have a separate consistent name space for the "private" properties and use different ones for the template file.

        e.g.

        derby.internal.install.url
        derby.internal.drda.host (describe what the property represents, not how it is used (security))

        or could use the existing namespace for runtime properties

        derby.__rt.

        Show
        Daniel John Debrunner added a comment - Same issue with 'derby.install.url'. Both of these properties are marked as 'private to derby' in their javadoc, but yet there are exposed in the template file. I wonder if it would be clearer to have a separate consistent name space for the "private" properties and use different ones for the template file. e.g. derby.internal.install.url derby.internal.drda.host (describe what the property represents, not how it is used (security)) or could use the existing namespace for runtime properties derby.__rt.

          People

          • Assignee:
            Unassigned
            Reporter:
            Daniel John Debrunner
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development