Re: [wildfly-dev] problems with the Elytron permission-mapping config model

Ok so lets switch this another way. If the addition from other subsystems was to be eliminated is there still a provisioning issue?

On Fri, 23 Mar 2018 at 20:52 Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse < > darran.lofthouse(a)jboss.com&gt; wrote: > >> On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky < >> alexey.loubyansky(a)redhat.com&gt; wrote: >> >>> On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <fjuma(a)redhat.com&gt; wrote: >>> >>>> A solution to part of the problem mentioned in WFCORE-3596 that was >>>> discussed is to introduce the concept of named permission sets. In >>>> particular, instead of having a permission-mapping reference permissions, >>>> it would instead reference named permission-sets. This would allow the >>>> provisioning tool to be able to add/remove permissions to/from a default >>>> permission-set based on the presence/absence of a specific subsystem when >>>> generating the default configuration. However, as Alexey pointed out, this >>>> doesn't solve the problem of knowing which permission-mapping a >>>> permission-set should be added to when attempting to preserve user >>>> configuration changes for patching, version updates, etc. >>>> >>> >>> Right. It does not change the permission-mappings, they remain to be a >>> list of items with no identity. Which is the fundamental problem. >>> >> >> But why is that a problem? I think that is the piece still missing. >> >> By moving the list of the permissions into a single named resource the >> tooling no longer has a need to be performing the manipulation within the >> simple permission mapper so that can be left to the administrator to look >> after independently. >> > > Is your question why is it a problem to give these things an identity? If > so, I have the same question, although I don't think Alexey's the one to > come up with the identity. > > Or is your question why is not having an identity a problem? If so, is it > correct to say that getting rid of this bit of wrongness is the problem: > > https://github.com/wildfly/wildfly-core/blob/master/ > elytron/src/main/resources/subsystem-templates/elytron.xml#L125 > > Basically right there elytron is speculatively providing configuration > rightly owned by other subsystems. To do this correctly, each of those > permissions should be part of the config established by other parts of the > system. The provisioning tool is expected to do it correctly. And doing > that requires some sort of identity for each item in the set. . Installing > a feature should involve adding independent, identifiable chunks of config, > not manipulating an attribute of some chunk of config owned by a different > feature. Manipulating an attribute is not feasible and isn't correct. > > >> >>> >>> Thanks, >>> Alexey >>> >>> Thanks, >>>> Farah >>>> >>>> On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < >>>> alexey.loubyansky(a)redhat.com&gt; wrote: >>>> >>>>> While this is addressed mainly to the Elytron team, it seems like we >>>>> would appreciate opinions from other colleagues since we are basically >>>>> stuck discussing possible ways to resolve https://issues.jboss.org/ >>>>> browse/WFCORE-3596 >>>>> >>>>> The description in the jira is pretty brief assuming people know what >>>>> that is about, since it's been raised before multiple times. Here is what >>>>> it is about fundamentally. >>>>> >>>>> If a configuration model (of a subsystem or any other component) >>>>> includes a list of configurable units (let's assume XML elements for >>>>> simplicity) that don't have any identity (unique id/name/path/etc) this is >>>>> a big problem for supporting patching and version updates preserving user >>>>> configuration changes. Or simply customizing the default config model using >>>>> a tool. By a big problem I mean it's simply not going to work reliably. >>>>> >>>>> As a simple exercise that demonstrates the issue, imagine you have >>>>> two configs each of which includes a list of these configurable units that >>>>> have no identity. Now try to identify the difference between the two lists. >>>>> Or merge them with one overwriting the other. Basically components w/o an >>>>> identity can not be manipulated. You can only add them but not modify or >>>>> even remove (unless their index in the list is a constant value of course). >>>>> >>>>> I don't think I've seen any issue of this kind in our (WF/EAP) >>>>> configs except for the Elytron's permission-mapping's. (If somebody knows >>>>> such components please let me know). >>>>> If I misunderstand the Elytron config model or approaching this from >>>>> a wrong angle, please let me know. >>>>> >>>>> Question for the Elytron team: is the problem I am describing clear? >>>>> Do you admit it as a problem? >>>>> >>>>> Thanks, >>>>> Alexey >>>>> >>>> >>>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat >