[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