db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
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 16:43:33 GMT
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.
> 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.
>  - 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?

If someone needs to crash the engine, then I am content that they crash 
the whole VM with it, just as they do today. I think that power is 
guarded by a grant of RuntimePermission( "exitVM" ).

>  - Ensure that the implementation follows the spec when it says that 
> Derby's permissions can be granted to code or other non-Derby Principals.
> With those changes to DERBY-2109 then the jmx beans could be expanded 
> to support valid jmx users as system administrators.
> Dan.

View raw message