db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2196) Run standalone network server with security manager by default
Date Wed, 07 Feb 2007 20:39:05 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471095
] 

Daniel John Debrunner commented on DERBY-2196:
----------------------------------------------

Can you update the functional spec with how these two properties ${derby.derby.jar} and derby.derbynet.jar
will be used by end users and what benefit having two properties provides? They seem to be
really strange to me as they will only ever be used by a policy file that has been modified
by the user. The network server might be using them internally when it boots using its own
default policy but that is really an implementation detail that is not relevant for user documentation.
Also I'm assuming that it is expected that derby.jar and derbynet.jar come from the same directory
location since derbynet.jar is dependent on derby.jar.

I am concerned that use of two properties leads to a policy file that has a potential security
risk in it. Namely that by setting these properties to point to other code, that code will
get a wide range of permissions including access to all files. The worst case is setting derby.derby.jar=
(empty string). That would seem to grant these permissions to all code.

Having the codebase in the policy file instead be something like
         ${derby.install.url}/lib/derby.jar
limits the exposure if there is a security hole where a remote user can set derby.install.home.

Of course maybe there is some benefit to the two properties as you have described them, and
I'm just not seeing it.



> Run standalone network server with security manager by default
> --------------------------------------------------------------
>
>                 Key: DERBY-2196
>                 URL: https://issues.apache.org/jira/browse/DERBY-2196
>             Project: Derby
>          Issue Type: Improvement
>          Components: Network Server, Security
>            Reporter: Daniel John Debrunner
>         Assigned To: Rick Hillegas
>         Attachments: derby-2196-01-print-01.diff, derby-2196-01-print-02.diff, derby-2196-01-print-03.diff,
secureServer.html, secureServer.html, secureServer.html, secureServer.html, secureServer.html,
secureServer.html
>
>
> From an e-mail discussion:
> ... Derby should match the security  provided by typical client server systems such as
DB2, Oracle, etc. I 
> think in this case system/database owners are trusting the database 
> system to ensure that their system cannot be attacked. So maybe if Derby 
> is booted as a standalone server with no security manager involved, it 
> should install one with a default security policy. Thus allowing Derby 
> to use Java security manager to manage system privileges but not 
> requiring everyone to become familiar with them.
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200612.mbox/%3c4582FE67.7040308@apache.org%3e
> I imagine such a policy would allow any access to databases under derby.system.home and/or
user.home.
> By standalone I mean the network server was started though the main() method (command
line).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message