db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Zaun (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2109) System privileges
Date Thu, 07 Feb 2008 13:18:09 GMT

     [ 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.


Mime
View raw message