[
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 clearer.
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 etc.
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/[EMAIL
> PROTECTED]
> 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.
-
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
