Rick Hillegas (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573110#action_12573110 ]
Rick Hillegas commented on DERBY-2109:
--------------------------------------
I would allow a patch which didn't work on Java 6 if it got other people
unstuck and if I trusted the developer to submit a fix soon.
I don't know the extent of the j2me issue, but it does not seem like a
good idea to allow a patch that knowingly will break the entire system
on a specific JVM. I would not submit a patch that caused all tests to
fail on a JAVA 6 jvm run, this could basically make it impossible for
some community members to develop in their current environment until it
was addressed. I would be ok for the sake of concurrent development to
check in a patch which had the functionality somehow disabled so that
multiple people could "enable it" in their environment to make it work
while not forcing others to suffer. I do understand that it is a pain
to joint develop in patches rather than in the svn source system.
Again I don't how easy this would be in this case.
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, DERBY-2109-09.diff,
DERBY-2109-09.stat, DERBY-2109-10.diff, DERBY-2109-10.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).
