[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467923
]
Daniel John Debrunner commented on DERBY-2109:
----------------------------------------------
These two sentences jump out at me:
"The Release Notes and user guides will advise the customer that this should
probably be customized."
"Again the Release Notes and user guides will advise the customer to restrict
these grants."
This is basically saying that we provide a "Basic policy" but we recommend
against its use.
So this overall work is adding three policies, "basic", "custom" and "open",
but the functional specifications are written to say one should use the custom
policy and the other two are not recommended. That just seems strange, why go
to all this bother since the custom policy can be done today, with no changes.
:-)
Maybe we need to add a property for system authorization that specifies the
default system administrator?
derby.system.defaultAdministrator
then the policy file could use DatabasePrinciple
"${derby.system.defaultAdministrator}" rather than being wide open.
Maybe if derby.system.defaultAdministrator was not set it would default to "*".
Another choice to to require the -u/-p arguments when starting the network
server on the command line. Then the default user would be that matching -u.
Then the basic policy could be useful by itself.
Though the functional spec says:
"The Basic policy file grants this permission to everyone."
maybe the "everyone" is misleading here, as really its every user successfully
authenticated against System authentication.
> System privileges
> -----------------
>
> Key: DERBY-2109
> URL: https://issues.apache.org/jira/browse/DERBY-2109
> Project: Derby
> Issue Type: New Feature
> Components: Security
> Affects Versions: 10.3.0.0
> Reporter: Rick Hillegas
> Attachments: systemPrivs.html, systemPrivs.html, systemPrivs.html
>
>
> Add mechanisms for controlling system-level privileges in Derby. See the
> related email discussion at
> http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
> The 10.2 GRANT/REVOKE work was a big step forward in making Derby more
> secure in a client/server configuration. I'd like to plug more client/server
> security holes in 10.3. In particular, I'd like to focus on authorization
> issues which the ANSI spec doesn't address.
> Here are the important issues which came out of the email discussion.
> Missing privileges that are above the level of a single database:
> - Create Database
> - Shutdown all databases
> - Shutdown System
> Missing privileges specific to a particular database:
> - Shutdown that Database
> - Encrypt that database
> - Upgrade database
> - Create (in that Database) Java Plugins (currently Functions/Procedures,
> but someday Aggregates and VTIs)
> Note that 10.2 gave us GRANT/REVOKE control over the following
> database-specific issues, via granting execute privilege to system
> procedures:
> Jar Handling
> Backup Routines
> Admin Routines
> Import/Export
> Property Handling
> Check Table
> In addition, since 10.0, the privilege of connecting to a database has been
> controlled by two properties (derby.database.fullAccessUsers and
> derby.database.defaultConnectionMode) as described in the security section of
> the Developer's Guide (see
> http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
