[ https://issues.jboss.org/browse/WFLY-1838?page=com.atlassian.jira.plugin.... ] Kabir Khan commented on WFLY-1838: ---------------------------------- 1) do you mean this? {code} [standalone@localhost:9990 /] /subsystem=datasources/data-source=*:read-resource-description { "outcome" => "success", "result" => [ { "address" => [ ("subsystem" => "datasources"), ("data-source" => "ExampleDS") ], "outcome" => "success", "result" => { "description" => "A JDBC data-source configuration", "access-constraints" => {"application" => {"data-source" => {"type" => "datasources"}}}, "attributes" => { --SNIP-- "security-domain" => { "type" => STRING, "description" => "Specifies the security domain which defines the javax.security.auth.Subject that are used to distinguish connections in the pool", "expressions-allowed" => true, "nillable" => true, "alternatives" => ["user-name"], "min-length" => 1L, "max-length" => 2147483647L, "access-constraints" => {"sensitive" => { "security-domain-ref" => {"type" => "core"}, "data-source-security" => {"type" => "datasources"} }}, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, --SNIP-- {code} If I include access-control=true I see the following under access-control {code} "access-control" => { "default" => { "read-config" => true, "write-config" => true, "read-runtime" => true, "write-runtime" => true, "attributes" => { --SNIP-- "security-domain" => { "read-config" => true, "write-config" => true }, --SNIP-- {code} So both read-config and write-config of security-domain are sensitive. For the read-resource I see security-domain filtered as I think it should since it is sensitive. {code} [standalone@localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:read-resource(){roles=MONITOR} { "outcome" => "success", "result" => { "allocation-retry" => undefined, -- SNIP - all the other attributes here, apart from security domain -- }, "response-headers" => {"access-control" => [{ "absolute-address" => [ ("subsystem" => "datasources"), ("data-source" => "ExampleDS") ], "relative-address" => [], "filtered-attributes" => [ "user-name", "security-domain", "password" ] }]} } {code} It seems to me it works the way it should, the sensitive attribute is filtered for MONITOR. If I do this as super user, security-domain is not filtered. I might be missing something. 2) a) If an attribute's access is sensitive it will not appear in either read-resource-description or read-resource. b) If it is read-config=true it will be filtered in read-resource. c) If it is write-config=true it could be non-filtered in read-resource, since as far as I know read-config=true is the trigger used for filtering (Brian will need to confirm that part) So if my assumption for c) holds true, you can not assume write values from if it is filtered in read-resource. It works the other way round, the description decides whether it is writable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira