On Mon, 13 Jun 2022 at 19:12, Chris Lambertus <c...@apache.org> wrote: > > > > > On Jun 13, 2022, at 10:57 AM, Sam Ruby <ru...@intertwingly.net> wrote: > > > > On Mon, Jun 13, 2022 at 1:06 PM Chris Lambertus <c...@apache.org > > <mailto:c...@apache.org>> wrote: > >> > >>> On Jun 12, 2022, at 4:54 PM, sebb <seb...@gmail.com> wrote: > >>> > >>> If the problem is just that recreating ou=meta is messy, then there > >>> are other solutions. > >>> > >>> For example, it should not be too difficult to compare the lists and > >>> only update those which have changed. > >>> Probably can also speed this up by comparing last updated dates. > >>> > >>> It might also make sense to enhance Whimsy to update the ou=meta list > >>> at the same time as the owners. > >>> As Sam points out this would require that the karma needed must agree > >>> with the karma for owners. > >> > >> Yes, this whimsy enhancement is ultimately what my proposal is -- update > >> whimsy to maintain the pmc groups with instead of having a separate > >> drop/parse/create system as we do now. I am not sure what you mean by > >> "karma needed must agree" though. Are you referring to LDAP ACLs? if so, > >> the policy would already allow this if the ou is under ou=groups. > > > > I preface the following by stating that what I am about to say may be > > a result of my ignorance of LDAP configuration capabilities, but I > > believe the crux of the issue can be found on the following line: > > > > https://github.com/apache/infrastructure-p6/blob/d0e1160c2a5d0a7f6b91978933333f126f80013f/modules/ldapserver/templates/slapd.conf.erb#L321 > > > > <https://github.com/apache/infrastructure-p6/blob/d0e1160c2a5d0a7f6b91978933333f126f80013f/modules/ldapserver/templates/slapd.conf.erb#L321> > > > > What that line says is that (in addition to root, secretary, pmc > > chairs, and the secretarial team) members of [P]PMCs can edit their > > own group. So, for example, PMC members (owners) can add/remove > > committers (members). > > I see what you mean. If whimsy is using the auth context of the logged-in > user, then they would not be able to write to a theoretical > cn=whimsy-pmc,ou=pmcs,ou=group,dc=apache,dc=org because the group such as > cn=whimsy-pmc would only contain 'member' attributes. > > Given the ACL, this -would- work if they were an ASF Member, a PMC Chair, or > Secretary. The workaround here would be to add both owner and member > attributes, but then that begs the question, how are owners initially added? > By the Secretary? > > > Now for a thought experiment. If 'owner' is problematic for some > > tools, then what would an LDAP configuration look like with NO owners? > > It would look the same as it did prior to the owner/member migration, with a > separate objects for cn=project and cn=project-pmc. Since cn=project already > works fine, we just need to (re)add and populate cn=project-pmc with a member > attribute. (And possibly also a matching owner attribute as described above.)
Would that still allow PMC members to update the committer lists? > > What we would need is the ability to specify "members of groups in > > this subtree are authorized to write to CORRESPONDING groups in > > ANOTHER subtree". We have the ability to say that "members of THIS > > SPECIFIC group can write to THAT SPECIFIC group". And the ability to > > say "members of THIS SPECIFIC group can update that entire SUBTREE". > > But as far as I know (and this may very well be my ignorance), there > > is no way to grant corresponding members of one subtree update access > > to another subtree. > > I'm not sure about this either. I could easily update the genmeta script to > add both owner and member values instead of just member values, which would > then allow the ACL to work as expected. > > Does this seem like a reasonable approach? It seems quite complicated compared with just fixing the existing script to generate updates rather than recreating everything. > -Chris > > > > > >>> This would minimise process changes as well as minimising LDAP updates. > >> > >> This is the goal. > >> > >>> In case there are Infra scripts that update owners it would make sense > >>> to keep a regular check on the consistency of the lists. > >> > >> Yes, I have been looking to see if there are any infra scripts which would > >> need to be updated, but I currently believe the only active tooling is > >> within whimsy. > >> > >> -Chris > > > > - Sam Ruby > > > >>> Sebb > >>> On Mon, 13 Jun 2022 at 00:32, Sam Ruby <ru...@intertwingly.net> wrote: > >>>> > >>>> From a whimsy requirements perspective, the key requirement is that > >>>> PMC members can update LDAP the PMC (i.e., both the PMC and committers > >>>> lists). > >>>> > >>>> On Sun, Jun 12, 2022 at 6:56 PM sebb <seb...@gmail.com> wrote: > >>>>> > >>>>> On Sun, 12 Jun 2022 at 21:26, Chris Lambertus <c...@apache.org> wrote: > >>>>>> > >>>>>> > >>>>>> Hi folks, > >>>>>> > >>>>>> I have been working on some updates to the LDAP service, and I would > >>>>>> like to get rid of ou=meta,ou=groups,dc=apache,dc=org (or at least the > >>>>>> process which manages it.) > >>>>>> > >>>>>> Some history -- this ou was created to address a problem which arose > >>>>>> after project groups were converted to member/owner (INFRA-16188). The > >>>>>> Atlassian Crowd service that feeds authentication and authorization > >>>>>> for Jira and Confluence does not understand the "owner" concept. > >>>>>> > >>>>>> Infra had previously created local roles in cwiki and jira, and > >>>>>> generally pushed maintenance of memberships of said roles to the > >>>>>> project owners defined within cwiki and jira. Over time this grew > >>>>>> cumbersome, and we elected to switch to LDAP-based groups, but we only > >>>>>> had access via Crowd to the attr=member version of the groups, so we > >>>>>> could not assign PMC-based roles. > >>>>>> > >>>>>> Because of this, I created a stop-gap process which drops and reloads > >>>>>> ou=meta nightly, populating > >>>>>> ou=$project-pmc,ou=meta,ou=groups,dc=apache,dc=org with attr=member of > >>>>>> the PMC members. This process is awkward, and causes problems with the > >>>>>> LDAP audit logging system. > >>>>>> > >>>>>> I would like to gather feedback on re-creating and maintaining the > >>>>>> ou=pmc tree in parallel with the owner/member paradigm that is now in > >>>>>> place, specifically to support Crowd-based applications (which now > >>>>>> also include JFrog/artifactory,) or other 3rd party tooling which may > >>>>>> not understand member/owner. > >>>>>> > >>>>>> At this time, I believe the only ASF tooling which creates or modifies > >>>>>> the owner attribute of project groups is Whimsy, so any code > >>>>>> adjustments would likely have to happen here. > >>>>> > >>>>> AFAIK Whimsy is not the only place where accounts are created and PMC > >>>>> memberships updated; there are likely some Infra scripts that do so. > >>>>> > >>>>> It's not clear to me whether the existing owner attributes will be kept > >>>>> or not. > >>>>> Indeed I'm not clear what the proposal is. > >>>>> > >>>>>> What are your thoughts? > >>>>>> > >>>>>> Thanks, > >>>>>> Chris > >>>>>> ASF Infra >
