db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: JMX meeting system authorization (DERBY-2109 & 1387) WAS Re: [jira] Commented: (DERBY-1387) Add JMX extensions to Derby
Date Fri, 08 Feb 2008 17:14:26 GMT
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>> Rick Hillegas wrote:
>>> Daniel John Debrunner wrote:
>>>> Rick Hillegas wrote:
>>>>
>>>>> In order to use JMX to monitor/configure Derby (and other 
>>>>> applications), I think that the following is true:
>>>>>
>>>>> DerbyNet-Admin => JMX-Admin
>>>>> Engine-Admin => JMX-Admin
>>>>> DB-Admin => JMX-Admin
>>>>> OtherApp-Admin => JMX-Admin
>>>>>
>>> Right. "VM-Admin => JMX-Admin" is my shorthand for "If you are a 
>>> VM-Admin, then you are a JMX-Admin".
>>
>> It's also key to note that JMX-Admins can have different identities, 
>> so while OtherApp-Admin and DerbyNet-Admin may both be JMX-Admins, 
>> they may not be able to perform the same operations.
>>
>> Derby's JMX and DERBY-2109 should be coming together so that the 
>> policy file can grant shutdown permission to JMXPrincipal('dan') and 
>> if I connect via jmx then I can shutdown the server without having to 
>> provide additional authentication. I think Rick pointed out that it 
>> was strange to have to authenticate twice to shutdown the server.
> Just to be clear: What concerns me here is the customer experience. 
> Being repeatedly challenged for credentials is akin to swatting down 
> swarms of security-related browser popups. A good management tool ought 
> to be able to shield the administrator from these challenges.
> 
> The administrator of the Derby-powered app should be able to prevent 
> other JMX-Admins from shutting down the Derby-powered app. Derby 
> credentials seem to me to be the obvious way to do this.

Right, and explicitly allowing other JMX admins to shutdown Derby should 
also be allowed. It's about having flexibility and following the model 
of Java security. Derby may be embedded in a framework that performs all 
the required authentication and authorization, thus it should be 
possible to grant shutdown permission to Java Principals or Java code 
(which is what the spec says). There should be no requirement for Derby 
authentication to exist (but the specs says there is) if other code is 
handling security.

>> If the JMXPrincipal is not authorized to shutdown then an additional 
>> authentication step would be required to a become a valid (Derby) 
>> SystemPrincipal.
>>
>> 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)
> 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.

>>  - 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().
> 
> 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).

Thanks,
Dan.

Mime
View raw message