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.
