[
https://issues.apache.org/jira/browse/DERBY-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Zaun updated DERBY-2109:
-------------------------------
Attachment: DERBY-2109-09.diff
DERBY-2109-09.stat
Please, find attached the updated patch DERBY-2109-09, which reflects most
changes and comments made since the previous version (DERBY-2109-08):
1) Renamed class DatabasePrincipal to SystemPrincipal and permission
"shutdownEngine" to "shutdown".
2) Changed SystemPrincipal for the handling of user names:
2.1) I verified with both Sun's and IBM's JDK (1.5) that the wildcard
syntax for policy files, which isn't that well described in the official Java
documentation, is supported:
a) grant principal * * { ... }
which is the same as:
b) grant { ... }
which grants permissions to any user represented by any principal
class
c) grant principal org.apache.derby.authentication.SystemPrincipal * {
... }
which is with both JDKs the same as:
d) grant principal org.apache.derby.authentication.SystemPrincipal
"WILDCARD_PRINCIPAL_NAME" { ... }
which grants permissions to any declared SystemPrincipal user
2.2) removed support for our special characters *, @, and \, as was
suggested.
2.3) changed the server.policy, template.policy etc. for the new wildcard
syntax SystemPrincipal * { ... }
2.4) changed code and javadoc to reflect that the rules for Authorization
Ids, as described in the UserIdentifiers document, apply to SystemPrincipal
names.
I think this feature is only partially complete:
a) the policy
grant SystemPrincipal "EVE" { ... }
now matches user names EVE, eVe, or eve -- as it should.
b) as of now, the policy
grant SystemPrincipal "eve" { ... }
only matches user name eve, not EVE or eVe, so, admins have to
declare the policy grants using NORMALIZED names if they want case-insensitive
matching of names -- I understand we don't want this restriction. This issue
requires somewhat more investigation, the Java Security Runtime seems to be
doing unexpected things.
c) the policy
grant SystemPrincipal "\"eve\"" { ... }
only matches user name eve, not EVE or eVe -- as it should.
3) removed misleading comments in SystemPrincipal, SystemPermission, and
DatabasePermission about the non-localization of RuntimeException messages.
4) removed a backward compatibility issue when running with Java Security but
without Authentication. Under this configuration, users now don't have to
change their customized policy files, as it was intended from the beginning.
There is an implementation question, though: how to find out that we're
running effectively without Authentication?
Some code in EmbedConnection tests for instanceof
NoneAuthenticationServiceImpl:
// If authentication is not on, we have to raise a warning if
sqlAuthorization is ON
// Since NoneAuthenticationService is the default for Derby, it
should be ok to refer
// to its implementation here, since it will always be present.
if (authenticationService instanceof
NoneAuthenticationServiceImpl)
usingNoneAuth = true;
However, I thought this somewhat fragile and decided to test in
SecurityUtil for the property "derby.connection.requireAuthentication", which I
found to be a neccessary condition:
// for backward compatibility skip check for create-db authorization
// if we run without Authentication but with a SecurityManager;
// otherwise, users would have to extend any customized policies
final String reqAuthKey = Property.REQUIRE_AUTHENTICATION_PARAMETER;
final String reqAuthValue = PropertyUtil.getSystemProperty(reqAuthKey);
if (!Boolean.valueOf(reqAuthValue).booleanValue()) {
return;
}
Please, let me know your thoughts.
5) addressed a backward compatibility issue with the NetworkServerControl
protocol where the shutdown command had been changed to transmit the user
credentials. As Dan had pointed out, older NSC clients would raise exceptions
when trying to shut down a newer server. I've incremented the protocol's
version number for a clean, early failure with an indicative error message.
I don't think requiring current NSC clients for a new server is a major
restriction since the socket connections are local to the machine anyway.
6) I'm still looking into another comment by Dan on the Authorization checks in
SecurityUtil, which employ a fresh (=null) AccessControlContext with
Subject.doAsPrivileged() instead of storing/maintaining a ACC or using the
current thread's AccessControlContext (as with Subject.doAs()).
Thanks, Martin
> 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, 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.
