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 Tue, 16 Jan 2007 20:33:27 GMT

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

Daniel John Debrunner commented on DERBY-2196:

Looks good - some initial comments:

In the "Basic Policy" section the spec switches between stating the permissions will be granted
to "Derby" and granted to specific jar files. I think stating the specific jar files is much

No idea what this means:
   "permission to establish insulating classloaders per connection"

The section for not having derby.system.home set has a permission that references derby.system.home.

As an alternative to when derby.system.home is not set, consider having the network server
set derby.system.home to the current directory. This would then have a single format for the
policy file rather than two paths.

I don't think derbynet.jar needs permissions to access the database files, e.g. ${derby.system.home}/-

derby.jar does not need to be granted any SocketPermission

Should the socket permission in "Basic Startup Policy" have similar functionality to the one
in "Basic Shutdown Policy" in that localhost is used if -h is not used etc? Should the port
number be in the policy file?

Spec does not reflect the discussion on the list about other file permissions, e.g. for backup

I don't see (or understand) any rationale for the "Basic Shutdown Policy". What security hole
is this trying to close?
Maybe the answer to this could also explain why the other policy is called ""Basic Shutdown
Policy"", when it's the policy for a running server not just startup time.

I wonder why if the "Open policy" is not recommended a really easy way to use it is provided.

> 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
>         Attachments: 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
> By standalone I mean the network server was started though the main() method (command

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message