[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561087#action_12561087
]
Daniel John Debrunner commented on DERBY-2109:
----------------------------------------------
On the current patch itself I have some questions:
1) Since J2ME/CDC/Foundation does not support some of the security classes
used, how is this being handled? Seems like it isn't at the moment. I think a
new abstract method is needed in InternalDriver called shutdownCheck() is
needed that would do nothing in J2ME but call the checks (through SecurityUtil
in J2SE.
2) Any thought on backwards compatibility for the network shutdown command in
terms of the DRDA protocol? Seems like the on-wire format for the shutdown
command has changed by adding in the user and password fields. What happens if
an old version of Derby tries to shutdown a 10.4 server?
3) I'd like to see more comments around the use of doAsPrivileged (e.g. why is
this needed rather than doAs, why pass in a null ACC
and the nesting of doAsPrivileged in a doPrivileged call (why is this needed).
I'm not sure that the code is using these correctly and given this is security
code we need to understand why one is used instead of the other, rather than a
comment like "doAs is not strong enough" (in the test).
My gut feeling is that doAsPrivileged is correct for the network server
shutdown only, seems like doAs is needed in the embedded calls if this piece of
the functional spec is to be true:
Because we use Java Security to model system privileges, the shutdownEngine
and create privileges can be granted to code as well as to users.
> 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.1.4
> Reporter: Rick Hillegas
> Assignee: Martin Zaun
> Attachments: DERBY-2109-02.diff, DERBY-2109-02.stat,
> derby-2109-03-javadoc-see-tags.diff, DERBY-2109-04.diff, DERBY-2109-04.stat,
> DERBY-2109-05and06.diff, DERBY-2109-05and06.stat, DERBY-2109-07.diff,
> DERBY-2109-07.stat, DERBY-2109-08.diff, DERBY-2109-08.stat,
> DERBY-2109-08_addendum.diff, DERBY-2109-08_addendum.stat,
> SystemPrivilegesBehaviour.html, systemPrivs.html, 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.
