On 7/16/14, 1:21 PM, Brian Stansberry wrote:
On 7/15/14, 10:40 PM, Edward Wertz wrote:
> I've got a better broad solution to this now, but I'm having some trouble
figuring out how to create limitations on the functionality.
>
> I added a 'resolve-expressions' parameter to ':read-attribute', which
can enable the handler to simply call ModelNode.resolve() on the return value and replace
all the expressions with their runtime values from that server.
I assume you're referring to server-side handler,
org.jboss.as.controller.operations.global.ReadAttributeHandler?
You can't resolve expressions by calling ModelNode.resolve(), as that
doesn't account for all the resolution sources available in a WildFly
process, e.g. the security vault. An OperationStepHandler would do it
via OperationContext.resolveExpressions().
FYI, folks, Joe has done great work on this and has also been very
patient! See [1] which I hope to merge in the next day or so.
I was a bit off base in my last comment above. I don't actually want to
bring the security vault into the resolution process. The really nice
article on the vault by mentallurg at [2] outlines the theory of the
vault nicely. The whole point is the expression can be publicly
available, e.g. in the config file which might get passed around. But to
learn a secret you must have access to the vault itself, and that is a
carefully protected file.
Allowing a remote management client to read the vault via this feature
defeats the whole point. We don't let the existing :resolve-expression
op do this. I don't think our security schemes are such that we can say
that just because a user is an authorized WildFly admin (even an RBAC
SuperUser) that they are privileged in the user organization to read
their vault.
This isn't a difficult issue to deal with though; a simple added commit
on Joe's work takes care of it.
[1]
https://github.com/wildfly/wildfly-core/pull/192
[2]
https://developer.jboss.org/docs/DOC-48166
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat