[ 
https://issues.apache.org/jira/browse/DERBY-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569939#action_12569939
 ] 

Daniel John Debrunner commented on DERBY-3424:
----------------------------------------------

By log in I meant connect to the jmx of the remote jvm using jconsole. I was 
using jmx authentication and a security manager on the remote jvm (the one 
running Derby).
Apart from the permissions in the spec additional permissions need to be 
granted to JMXPrincipals, this works but is very general:

 grant principal javax.management.remote.JMXPrincipal * {
  permission javax.management.MBeanPermission "*", "*";
};

One can fine tune the MBeanPermission settings to allow only certain operations 
on certain beans and obviously different permissions for different users.
Every action on an mbean implictly requires an MBeanPermission  permission.

I also discovered on the server side one can use -Djava.security.debug=access 
to produce a log of access permissions, which helps in setting up any policy 
file.

> Add an MBean that an application can register to change the state of Derby's 
> JMX management
> -------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3424
>                 URL: https://issues.apache.org/jira/browse/DERBY-3424
>             Project: Derby
>          Issue Type: New Feature
>            Reporter: Daniel John Debrunner
>            Assignee: Daniel John Debrunner
>            Priority: Minor
>
> JMX in Derby was originally proposed as a mechanism to configure Derby 
> replacing or enhancing the system properties which tend to be static in 
> nature. Thus it is somewhat ironic that jmx is enabled with a static system 
> property derby.system.jmx.
> I propose to add a public mbean that allows the state Derby's JMX management 
> to be changed. This bean is not automatically registered by Derby if 
> derby.system.jmx is false, but instead can be registered by an application. I 
> believe this could occur at any time so that JMX could be enabled on a 
> running application, possibly by a remote client.
> This standard Mbean (o.a.d.mbeans.Management & ManagementMBean) would have 
> these operations & attribute:
>     public boolean isManagementActive();
>     public void startManagement(); 
>     public void stopManagement();
> If Derby is not booted within the jvm then the operations would be no-ops.
> If derby.system.jmx is true then Derby will itself register an mbean that 
> implements ManagementMBean to allow dynamic control of the visibility of 
> Derby's mbeans.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to