[
https://issues.apache.org/jira/browse/DBCP-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14984942#comment-14984942
]
Mark Thomas commented on DBCP-448:
----------------------------------
JMX is an administrative interface where the only access control is read vs
read/write. It is, therefore, in my view, equivalent to root access to the JVM
and in that case making getPassword() return null is pretty much a pointless
exercise. I am not at all a fan of adding bloat to DBCP to address the lack of
fine-grained access controls in JMX.
Making getPassword() return null will break BasicManagedDataSource and may
break applications using DBCP.
If we add a property to control password exposure, we won't be able to set that
property via JMX. We would be creating an arbitary division between those
properties that are accessible via JMX and those that are not based on one
user's (in my view flawed) security model.
I do worry that this might be the start of a slippery slope.
I guess I could live with a getPasswordJMX() method along with a
hidePasswordForJMX or similar property as long the the default behaviour
remained unchanged but I wouldn't be very happy about it.
> Disable password exposure via JMX.
> ----------------------------------
>
> Key: DBCP-448
> URL: https://issues.apache.org/jira/browse/DBCP-448
> Project: Commons Dbcp
> Issue Type: Improvement
> Affects Versions: 2.1
> Reporter: Michał Jedynak
> Priority: Minor
>
> Currently there is no control over which methods are exposed as mbeans via
> JMX in BasicDataSource.
> The main issue with this approach is that 'getPassword' method is also
> exposed which is most of the time problematic on production environments.
> It would be nice to have some control over the exposed methods to be able to
> disable password exposure.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
