[wildfly-dev] Automatically resolving expressions in the CLI

Brian Stansberry brian.stansberry at redhat.com
Mon Sep 22 10:55:36 EDT 2014

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

More information about the wildfly-dev mailing list