db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3462) Require new permissions in o.a.d.security.SystemPermission to allow control to Derby's JMX management and to ensure information is not leaked through JMX
Date Fri, 14 Mar 2008 11:57:36 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578702#action_12578702

John H. Embretsen commented on DERBY-3462:

I must admit it is not easy to follow all the commits going on in this area (system permissions
and JMX). I hope others are able to look at these changes as well, eventually.

In the default server policy, the following is granted to derby.jar:

  // Gives permission for jmx to be used against Derby but
  // only if JMX authentication is not being used.
  // In that case the application would need to create
  // a whole set of fine-grained permissions to allow specific
  // users access to MBeans and actions they perform.
  permission org.apache.derby.security.SystemPermission "jmx", "control";
  permission org.apache.derby.security.SystemPermission "engine", "monitor";
  permission org.apache.derby.security.SystemPermission "server", "monitor";

Does this mean that these permissions serve no purpose if JMX authentication is enabled? Or
are these permissions needed in addition to any user-specific fine-grained permissions in
that case?
I have not studied the code in detail yet, but I'm trying to understand the comments independently
from that...

Regarding permission usage, I don't think I fully understand the reasoning behind it, but
I guess that is to be expected given the following sentence from the wiki:
"Exact use for these various permissions may become clear as attributes and operations are
added to MBeans (and new MBeans added)."

For others trying to understand this, here are some notes (ramblings) I've made that may of

Control is defined as "Permission to perform control actions through JMX on engine, server
or jmx".
Monitor is defined as "Permission to perform monitoring actions through JMX on engine and

Reading the following NetworkServerMBean attributes require the ("server", "control") permission:


The rest of the actions require the "monitor" permission. Both permissions are granted to
the network server in the default policy.

I do understand that "control" is used for attributes that are deemed more security sensitive
than others. Intuitively, though, I would say that *all* the current NetworkServerMBean actions
are monitoring actions, not control actions, but I guess I'll get over it...
I guess "control" seems more like a description of a role than a specific action at this point.

If both permissions ("control" and "monitor") are included for the network server in the default
policy file, why don't we leave distinguishing between sensitive actions and non-sensitive
actions to the admin? Admins may have different views of which actions are security sensitive
and which are not...  I guess if JMX authentication is enabled this (fine-grained permission
grants) is still possible...

> Require new permissions in o.a.d.security.SystemPermission to allow control to Derby's
JMX management and to ensure information is not leaked through JMX
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-3462
>                 URL: https://issues.apache.org/jira/browse/DERBY-3462
>             Project: Derby
>          Issue Type: Sub-task
>          Components: JMX, Security
>            Reporter: Daniel John Debrunner
>            Priority: Minor
> Plan is to implement proposal defined in:
> http://wiki.apache.org/db-derby/JMXSecurityExpectations#head-de15a7e9d474784775933965fe963b6ac46e7ad0
> E.g.
> jmxControl for the ability to call the operations on ManagementMBean.

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

View raw message