We need to properly describe in the docs that we actually have TWO kinds of non-addressability: intentional and non-intentional. The reason we need this documented is that in the future, we probably will want to make the non-intentionally non-addressable resources addressable (and non-readable). This might be considered a regression by some customers, which is what the documentation should prevent. Why could such change be considered a regression? If an address of a resource contains sensitive data (like a name of a security domain), then the resource must be non-addressable [for roles that can't read sensitive data]. Thus, non-addressability is a security measure. If we change non-addressable resource to addressable & non-readable in the future, customers might get a feeling that we are weakening the security of the system. Why would we want to make some non-addressable resources addressable in the future? Some resources that are now non-addressable are actually NOT meant to be (see e.g. bug 1015524). They are meant to be addressable & non-readable, but the web console doesn't support this combination yet (see https://issues.jboss.org/browse/HAL-283). So they being non-addressable is a workaround and we intend to do a proper solution in the future. It can't happen in EAP 6.2 due to time constraints, though. Brian explained the situation quite clearly: "One possible way to document this is that users should only consider non-addressability that results from the sensistivity classification configs to be a stable contract. The fact that scoped roles can't address certain otherwise non-sensitive resources may, and likely will, change in a later release." Incidentally, the documentation states in 10.8.2 that "If you do not have permissions to access a resource or attribute at all (it is "unaddressable" for your role) then it does not appear in the console at all for you. An example of that is when a role is scoped to a server group, other server groups will not be visible." This is a perfect example of non-addressable resource that is NOT meant to be non-addressable and that will likely change to addressable in the future. This example should be changed to something else. For more background on this issue, see bug 1019784 and/or this thread on wildfly-rbac: http://post-office.corp.redhat.com/archives/wildfly-rbac/2013-October/msg00017.html. CC'ing Darrin as RBAC documentation author, Brian as dev owner, Pavel as QE manager and John and Mark as PM, so that noone misses this.
Do we think we know the full permutations of the non-intentionally non-addressable resources? Can we list them in a release note to make clear that the interactions around these resources may change?
John, For server group scoped roles this details the addressability behavior in 6.2: The Server Group Scoped Role will include privileges for the following resource trees logically related to the server group: Profile Socket Binding Group Deployment Deployment override Server group Server config Server Resources in the profile, socket binding group, deployment, deployment override, server group, server config and server portions of the tree that are not logically related to a server group associated with the Server Group Scoped Role will not be addressable by a user in that role. So, for example, in a domain with server groups “a” and “b”, a user in a Server Group Scoped Role that grants access to “a” will not be able to address /server-group=b. The system will treat that resource as non-existent for that user. Nor will it be able to address profiles, socket binding groups, deployments, or deployment overrides that are associated with server group "b" unless they are also associated with server group "a". For host scoped roles this details the addressability behavior in 6.2: Resources in the /host=* portion of the tree that are unrelated to the hosts specified for the Host Scoped Role will not be visible to users in that Host Scoped Role. So, in a domain with hosts “a” and “b”, a user in a Host Scoped Role that grants access to “a” will not be able to address /host=b. The system will treat that resource as non-existent for that user. We expect (but are not 100% certain) that in later releases some or all of these resources will be addressable, but they will not be readable. To clarify that distinction, a resource is addressable if the existence of its address can be confirmed via the management API; e.g. the response to /:read-children-names(child-type=server-group) would include "b" if it is addressable by the caller and would not include it if it isn't. It is readable if its contents can be read. Please see https://bugzilla.redhat.com/show_bug.cgi?id=1015524 for an example of the kind of usability issues having these resources not be addressable causes. Making them non-addressable was meant to improve usability by presenting the user with a view of the domain as it would appear if nothing existed outside his or her scope. But this view does not truly reflect reality, and unfortunately reality intrudes, a la the #1015524 case. So it is probably better to allow the user to know of the existence of resources (the names of which are not sensitive).
A couple further notes to round out the picture of what scope roles can do: In addition to the privileges described in the previous comment, users in a Host Scoped Role will have non-sensitive read privileges (equivalent to the Monitor role) for domain wide resources (i.e. those not in the /host=* section of the tree.) In addition to the privileges described in the previous comment, users in a Server Group Scoped Role will have non-sensitive read privileges (equivalent to the Monitor role) for resources other than those listed above.
Did anything change in the 6.3 timeframe, or are we still on the same page here? If nothing changed, we will probably want this documented in 6.3 release notes as well.
I just realized that I used the "on the same page" idiom wrongly. Not a native speaker, sorry. Let me rephrase: Did anything change in the 6.3 timeframe, or is it still the case that non-addressable resources exist that in fact should be addressable but non-readable? If nothing changed, we will probably want this documented in 6.3 release notes as well.
Nothing has changed, so yes, the existing Known Issue note should be carried forward.
I have begun work on this BZ ticket, adding to the following topic to clarify "addressibility". About Role-Based Access Control (RBAC) [23145]
We agreed that a Known Issue entry in Release Notes is enough for this and no additional changes in documentation are needed. Maybe the flags on this bug made the impression that documentation work is required?
Attention: Ladislav Thank you for your message. I had begun work on adding to the documentation, thinking that it needed to be included. I will now stop that work, as you have confirmed that only the Release Notes entry is required.
I have now removed the added text from the following topic: About Role-Based Access Control (RBAC) [23145]
The text is of course OK, as it didn't change, but looking at [1], it's marked "private" and maybe it won't be visible? We had this entry in release notes added manually in the past (see e.g. 6.2.0 release notes at [2]) and we should have it added like that for 6.3.0 too. Moving back to assigned. [1] https://documentation-devel.engineering.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6.3/html-single/6.3.0_Release_Notes/index.html [2] https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.2/html-single/6.2.0_Release_Notes/index.html Reviewed in Revision 6.3.0-12. P.S.: also note that it's likely we will want this entry in release notes in 6.4 too. So I'm not going to mark this "verified" even when it will be correct. Sounds disappointing, but I don't see a better way.
No problems with that approach Ladislav. I need this bug open as a reminder anyway. But I'm going to move it to POST, so I (and others) know there's been work done on it.
A new build of the 6.3.0 Release Notes is available for review at: https://documentation-devel.engineering.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6.3/html-single/6.3.0_Release_Notes/index.html When verifying bugs, please ensure you're viewing the latest version of the document (6.3.0-14 or later) Build details: https://brewweb.devel.redhat.com/taskinfo?taskID=7700244
I'm looking at Revision 6.3.0-14 and this is still shown as "private"?
D'Oh! Sorry Ladislav. Total brain-hiccup on my part with this! I have the text saved locally, but it was initially exported from this bug (which is private). I need to remember to manually remove that XML for the next build.
Wow, I didn't think that adding stuff manually is _that_ involved. I mean, we absolutely must get rid of manual additions to release notes, it's crazy and error-prone as hell. Would it work better for you if I created a public bug that didn't contain any discussion and details? Then, we could get rid of the process around this bug, and we could even have different bugs for 6.3 and 6.4 (if needed), so the proper BZ process can be followed... What do you think?
I appreciate the offer Ladislav, but to be honest, there's always going to be a few unique cases each release that aren't going to fit neatly into the automated process and need to be dealt with manually. This one is resolved now. I've removed the XML markup that highlighted this entry as private. It won't appear that way in any future builds.
This is fine in current version of 6.3.0 release notes (Revision 6.3.0-17). I'm moving this to POST as per comment 16 and consider this bug finished from 6.3 perspective. Please don't move to ON_QA or any other state -- we will need this bug for 6.4 as well.
Tom, we agreed that it is enough to document this in release notes and no other documentation is needed. Why the component change?
Turns out this is a mass change in documentation-related bugs, this one just was first in my inbox. Clearing the needinfo flag.
Scott, how are we going to handle this release notes item in 6.4? I'm not aware of any changes in this area, so I guess that we will still want to have this documented. Shall we open a new BZ for that when the time comes?
Brian, it's that time of the year again :-) Did anything change in the 6.4 timeframe, or is it still the case that non-addressable resources exist that in fact should be addressable but non-readable? If nothing changed, we will want this documented in 6.4 release notes as well.
Nothing has changed.
Scott, how are we going to handle this in 6.4 release notes? We need to carry the existing Known Issue forward. Do you want me to create a new BZ, given that you closed this one 2 months ago?
Reopening so that this isn't forgotten. We still need to add the Known Issue text manually to the Release Notes, this time for 6.4.