db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Zaun <Martin.Z...@Sun.COM>
Subject Re: JMX meeting system authorization (DERBY-2109 & 1387) WAS Re: [jira] Commented: (DERBY-1387) Add JMX extensions to Derby
Date Sat, 09 Feb 2008 06:05:53 GMT

My (detail) comments and a few questions below.

Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>>>
>>> For this mode to be enabled some changes are needed to DERBY-2109:
>>>
>>>  - Enforce Derby's security permissions if there is a security 
>>> manager (regardless of Derby's authentication state)

Like Rick, I'm also ok with this.  But I'd just like to refresh our
memory that the reason we'd made the checks for System Privileges
dependent on Derby's authentication was backward compatibility for
users
- with customized policy files running
- with a Security Manager (default) but
- no authentication (default);
because they will have to extend their policy files for two blocks
of permissions:

grant codeBase "${derby.install.url}derby.jar" {
   ...
   permission javax.security.auth.AuthPermission "doAsPrivileged";
   permission java.util.PropertyPermission "user.dir", "read";   // unless granted already
   permission java.io.FilePermission "${user.dir}${/}-", "read"; // unless granted already
}

grant principal org.apache.derby.authentication.SystemPrincipal * { // or specific user
   permission org.apache.derby.security.SystemPermission "shutdown";
   permission org.apache.derby.security.DatabasePermission "directory:<<ALL FILES>>",
"create";
};

>> I'm ok with this. However, I don't want to hold up the good work done 
>> so far on DERBY-2109. Unless there are strong objections, I'm inclined 
>> to commit the current patch. As a follow-on patch, we can then make 
>> the Derby permissions-checker preserve the other identities which the 
>> invoker may have.
> 
> I fine with the patch going ahead and the preserving of identities being 
> a follow on, but this point is about not checking for the existance of 
> Derby's authentication before invoking security manager checks. It seems 
> somewhat pointless to have that in the patch (along with tests?) only to 
> remove it as a follow on.

Glad to hear that there are no other major obstacles for going forward.

>>>  - Continue to support shutting the network server & engine down 
>>> without authentication credentials but only from within the same 
>>> virtual machine. This shutdown would require the Derby shutdown 
>>> permission if a security manager was installed.
>> Just to be clear: In order to gracefully shutdown the engine today, 
>> you need to get a shutdown connection to the engine. If authentication 
>> is enabled, then you must present credentials in order to get that 
>> connection. If you can't get a shutdown connection, then you can't 
>> shutdown the engine gracefully--although you can crash the engine 
>> along with the rest of the VM by calling System.exit().

Let me recap the shutdown behaviour with DERBY-2109 (as specified and
implemented) plus what I think you, Dan, would like to see changed:

1) To shutdown the engine:

    a) From a jdbc client with a shutdown URL (remote and embedded):
       clients need to provide user credentials if and only if running
       with authentication "on".  Nothing changes here with DERBY-2109.

       Not sure: For the embedded case with Derby authentication "on",
       was it suggested to drop the requirement for providing user
       credentials with the URL shutdown request?

    b) When running Derby within the same JVM as the application: I wonder
       if user code can bypass our authentication and authorization checks
       by calling directly:
         org.apache.derby.iapi.services.monitor.Monitor.getMonitor().shutdown()

    c) Also, I wonder if this Monitor.getMonitor().shutdown() trick can be
       done from Procedures?  Or is this prohibited by the ClassLoader?

2) To shutdown the server:

    a) From a separate process (on the same host as the Derby server):
       users can run NetworkServerControl "shutdown" command or call the
       shutdown() method on a NetworkServerControl instance.

       With DERBY-2109, the NetworkServerControl's "shutdown" command now
       supports user/password arguments.  Also, an extra constructor for
       NetworkServerControl takes user credential arguments, which are
       stored and passed when the shutdown() method is invoked (for API
       backward compatibility).  User credentials must be provided if and
       only if running Derby with authentication "on".  In addition,
       DERBY-2109 checks for authorization if running with authentication
       and a SecurityManager.

       I understand that
       - NetworkServerControl's shutdown authentication support as
         implemented in DERBY-2109 is ok, but
       - the shutdown authorization check should NOT be made dependent
         upon prior authentication but Java Security only.
       Right?

    b) For running a Derby server within the same JVM as the application
       I see two options:
       - user code may call the shutdown() method on any
         NetworkServerControl instance (which sends the request via a
         socket connection to the server within the same process);
       - user code can create an instance of NetworkServerControlImpl,
         start the network server by calling start() on this instance,
         and later bring it orderly down by calling directShutdown() on
         the same (!) instance.

       With DERBY-2109, there's an additional NetworkServerControlImpl()
       constructor taking user credential arguments.  Again, credentials
       are required if (and only if) running Derby with authentication
       "on".  We check for authorization if running with authentication
       and a SecurityManager.

       The formerly public method that unconditionally shuts down the
       server has now become private to prevent a program from bypassing
       the authentication and authorization checks and been renamed to
       directShutdownInternal().

       I understand that as with 2a), the authorization check should NOT
       be made dependent upon prior authentication.

       However, I'm not sure about the authentication behaviour:  Do we
       need a NetworkServerControlImpl method (for in-process-clients)
       that bypasses Derby's authentication but does check for
       authorization before shutting down the server?

       Even more: Should the method directShutdownInternal() be made
       public, so that callers within the same JVM can bypass both the
       shutdown authentication and authorization checks?

       Note that any direct shutdown needs to be invoked on the same
       NetworkServerControlImpl instance that started the server, so,
       any such caller first needs to get hold of a reference.

>> Is there some other change we should make to the DERBY-2109 behavior 
>> beyond the change discussed in the previous bullet?
> 
> I think there's additional functionality, but it's a follow on to 
> DERBY-2109. That issue is already taking on too much, better to have a 
> separate clear issue. I'll enter one (which will be dependent on 
> DERBY-2109).

Well, we've changed the DERBY-2109 spec before :)  But I'd appreciate
if the patch can be committed soon and cleanup/extension/optimization
items on System Privileges are handled in a separate JIRA.

Thanks,
Martin

Mime
View raw message