[jboss-jira] [JBoss JIRA] (WFCORE-1148) Non runtime-only operation can be invoked in domain servers

[Brian Stansberry (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132256#comment-13132256 ] 

Brian Stansberry commented on WFCORE-1148:
------------------------------------------

This is by design. The enforcement of rejecting end-user requests to servers is done by OperationContextImpl if the OSH attempts to make a call involving write access to the configuration model.

We can't drop that check, as it's the critical safeguard. Relying on accurate metadata to do security enforcement is weaker than just preventing the low level check.

OTOH, you make a good point in IRC that it's bad to hide ops in things like read-operation-names that can actually be invoked. The limitation in read-operation-names is based on the metadata.

Making that consistent though would mean rejecting requests if the OperationDefinition didn't report the op as being runtime-only. That would further break subsystems, particular concern being external ones not tested by our testsuite, that have problems like WFLY-5418.

That might be an ok thing to do; I'm somewhat in favor, but IMHO it's too late for that. It needs to be in an early Beta release for a Major, and really that means an EAP major, not just a WildFly one.

In HipChat you mentioned the "describe" op. That's a somewhat different case where we don't report the op in the API because it's marked private, but we make it accessible. Same thing applies to "composite". Really we should just make those public. Theres' a JIRA for doing that for "composite". The only reason I haven't done that one is a lame concern that the description for these is not "complete", i.e. the params and responses are not fully described (and can't be.) That's kind of lame though. Obviously the system is massively impaired if "composite" can't be called by a user.

If we made "composite" and "describe" public, rejecting end user calls to private methods would be more feasible. It has similar issues in terms of potential breakage and being "too late for this major" as rejecting non-runtime-only would. It should be a smaller issue, as I don't expect subsystem to have private ops that users are meant to invoke anyway. Really that's kind of a bug in the subsystem. :)

> Non runtime-only operation can be invoked in domain servers
> -----------------------------------------------------------
>
>                 Key: WFCORE-1148
>                 URL: https://issues.jboss.org/browse/WFCORE-1148
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.2.Final
>            Reporter: Jeff Mesnil
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> While working on WFLY-5418, I noticed that non runtime-only operations can be invoked on domain servers under /host=X/server=Y/...
> The operation is not listed in read-operation-names, read-resource-description, etc. but invoking it is still possible.
> Brian confirmed that this is a bug and the operation should not be executed.
> Steps to reproduce:
> * remove the runtimeOnly flag in org.jboss.as.ejb3.subsystem.deployment.MessageDrivenBeanResourceDefinition#registerOperations
> * deploy the quickstart helloworld-mdb
> * the start-delivery (and stop-delivery) operations are not listed in /host=master/server=server-one/deployment=wildfly-helloworld-mdb.war/subsystem=ejb3/message-driven-bean=HelloWorldQueueMDB:read-operation-names
> * But the method can be invoked by executing:
> {noformat}
> [domain at localhost:9990 /] /host=master/server=server-one/deployment=wildfly-helloworld-mdb.war/subsystem=ejb3/message-driven-bean=HelloWorldQueueMDB:start-delivery ain at localhost:9990 /]
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)