Page MenuHomePhabricator

Add legoktm to gerritadmin LDAP group (restoring previously held access)
Closed, ResolvedPublic

Description

I've been a Gerrit administrator since Chad made me one back in 2015[1], and have used it to mostly single handled manage the repository ownership requests process. Due to recent events, my administrator status was removed under the assumption that those rights weren't needed, but that turns out not to be the case[2]. Furthermore, https://www.mediawiki.org/wiki/Gerrit/Privilege_policy makes it clear that one needs to be a Gerrit administrator to enact the types of changes I used to in the past.

[1] Per T218761, but I can't even see the audit log to verify that anymore.
[2] Specifically, I can no longer edit membership in the mediawiki group, which is (correctly) owned by Administrators.

Event Timeline

Legoktm created this task.Mar 24 2019, 3:18 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 24 2019, 3:18 AM

+1. You shouldn't have been removed in the first place though.

administrator status was removed under the assumption that those rights weren't needed

The only reason I have dropped administrator right for most users, is that it grants way too many capabilities. Most of them are not needed for creating repositories or tweaking groups membership/ownership.

Specifically, I can no longer edit membership in the mediawiki group, which is (correctly) owned by Administrators.

Which turns out to be incorrect. Administrators group is really just to maintain the Gerrit instance. For mediawiki membership, we would just create a new group.

Anyway, @MarcoAurelio raised that blocker earlier and that got filled as T219012. Lets follow up there :]

hashar closed this task as a duplicate of Restricted Task.Mar 25 2019, 9:40 AM
Legoktm reopened this task as Open.Mar 25 2019, 3:47 PM

This is not a duplicate of T219012.

ema added a subscriber: ema.Apr 1 2019, 2:20 PM

Is there anything SRE needs to do here or are we waiting for the T219012 discussion to reach a consensus?

Legoktm added a comment.EditedApr 1 2019, 8:50 PM

Is there anything SRE needs to do here or are we waiting for the T219012 discussion to reach a consensus?

I would appreciate it if SRE could process this like a normal LDAP/access request. As I explained, the rights removal was incorrect, and should be undone.

Both T219012#5056478 and T219012#5057232 seem to agree that I should be re-added as an administrator, and there hasn't been any opposition (on that private task) after nearly a week.

If T219012 does eventually resolve with some other consensus then my groups should be adjusted accordingly.

RobH added subscribers: greg, RobH.Apr 2 2019, 11:10 PM

So, the process for processing shell requests changed recently to have the actual approval of membership into specific groups be handled by those group's managers. SRE comes into approvals on what that group is allowed to actually do when that group is implemented/setup.

Following that, I'd think approval into this group (gerritadmin ldap administration group) would fall more to the release engineering team, rather than SRE?

@greg: Your thoughts?

RobH assigned this task to greg.Apr 2 2019, 11:37 PM
greg added a comment.Apr 3 2019, 6:43 PM

The right answer here is to add Kunal to the Gerrit-Mangers group, I believe. Correct, @hashar ?

RobH reassigned this task from greg to hashar.Apr 3 2019, 7:58 PM
hashar added a comment.Apr 3 2019, 8:09 PM

The right answer here is to add Kunal to the Gerrit-Managers group, I believe. Correct, @hashar ?

Yes, the Gerrit Managers group used to be named Projects and groups creators which better reflects its intent. The Administrators group grants all capabilities, database and disk write. That is why I originally marked this request as a duplicate of T219012. That task is about fixing up permissions to allow Gerrit Managers to conduct their duties.

They have never been written in stone nor in a policy and there are a bunch of oddities we have to understand and document. I think we have locked down some groups so that they are only owned by Administrators to prevent mislead changes to projects ACL. Eg mediawiki.git` is owned by Administrators, people can still be granted permissions by being added to the mediawiki group, they are not able to change ACL of the mediawiki repositories.

The challenge there is to figure out the right groups/ownerships and ACL to apply on projects.

Perhaps in the meawhile we could restore @Legoktm access. Under the new Gerrit privilege policy (and because of how some groups are configured), Administrators are tasked with granting people access after successful requests. We have none currently, and looks kinda weird. We currently have T218864 which has support from maintainers and users but that apparently no one can action?

RobH reassigned this task from hashar to Legoktm.Apr 4 2019, 3:45 PM

Please note that both @greg and @hashar have suggested an alternative to granting the full administrator access. As release engineering is the maintainer of the actual gerrit software, it falls to them to approve/deny these kinds of requests.

As this has a discussion about administration group, not managers group, I'd suggest this be declined (not approved by service maintainers/release engineering) and a new task be filed to request addition to Gerrit-Managers group.

Alternatively, if @Legoktm wants to confirm that Gerrit-Managers would work for them, they can comment on this task and we can simply change this task to Gerrit-Managers rather than Gerrit Administrators. As such, I am assigning this to @Legoktm for their feedback.

The right answer here is to add Kunal to the Gerrit-Mangers group, I believe. Correct, @hashar ?

I don't understand why we're going in circles here. I'm already a member of Gerrit Managers, which as I've explained isn't sufficient (c.f. T218761#5051328). Both you and @hashar already know this.

If I am not trusted enough with device security or whatever to maintain Gerrit administrator status in the interim while other people figure out the ideal ACL, please just tell me, because then I can give up all the other significantly more privileged access I have.

Please note that both @greg and @hashar have suggested an alternative to granting the full administrator access. As release engineering is the maintainer of the actual gerrit software, it falls to them to approve/deny these kinds of requests.

This is of course, at odds with my understanding/interpretation of what another releng team member said at T219012#5056478 (which I linked to earlier in T219086#5075884). It's at odds with what a TechCom member proposed at T219012#5057232 to no opposition for a week.

As this has a discussion about administration group, not managers group, I'd suggest this be declined (not approved by service maintainers/release engineering) and a new task be filed to request addition to Gerrit-Managers group.

I think this would be pretty unfortunate. In addition being prevented me from doing the tasks I've been doing for years, I'm still effectively under a gag order about telling other people why.

Alternatively, if @Legoktm wants to confirm that Gerrit-Managers would work for them, they can comment on this task and we can simply change this task to Gerrit-Managers rather than Gerrit Administrators. As such, I am assigning this to @Legoktm for their feedback.

To be explicit: Gerrit Managers is currently not suitable for the tasks I was carrying out previously and plan to carry out in the future. Discussion is on-going to potentially change that, but I'm currently stalled and am asking for my previously held permissions (that were improperly removed) to be reinstated.

Legoktm removed Legoktm as the assignee of this task.Apr 5 2019, 8:03 AM
greg added a comment.Apr 5 2019, 6:02 PM

The right answer here is to add Kunal to the Gerrit-Mangers group, I believe. Correct, @hashar ?

I don't understand why we're going in circles here. I'm already a member of Gerrit Managers, which as I've explained isn't sufficient (c.f. T218761#5051328). Both you and @hashar already know this.

Again, we are trying to work towards what the best solution is. Don't take these discussions as slights against you.

I assumed the plan was to have Gerrit-Managers [nb: I was wrong, actually mediawiki-administrators per https://www.mediawiki.org/wiki/Topic:Ux3epfphh9qij5iw ] be the owner of mediawiki/ as well, not just Administrators.

If I am not trusted enough with device security or whatever to maintain Gerrit administrator status in the interim while other people figure out the ideal ACL, please just tell me, because then I can give up all the other significantly more privileged access I have.

See above.

Please note that both @greg and @hashar have suggested an alternative to granting the full administrator access. As release engineering is the maintainer of the actual gerrit software, it falls to them to approve/deny these kinds of requests.

This is of course, at odds with my understanding/interpretation of what another releng team member said at T219012#5056478 (which I linked to earlier in T219086#5075884). It's at odds with what a TechCom member proposed at T219012#5057232 to no opposition for a week.

See https://www.mediawiki.org/wiki/Topic:Ux3epfphh9qij5iw where the proposal is to have mediawiki-administrators (or so) for that use case.

Alternatively, if @Legoktm wants to confirm that Gerrit-Managers would work for them, they can comment on this task and we can simply change this task to Gerrit-Managers rather than Gerrit Administrators. As such, I am assigning this to @Legoktm for their feedback.

To be explicit: Gerrit Managers is currently not suitable for the tasks I was carrying out previously and plan to carry out in the future. Discussion is on-going to potentially change that, but I'm currently stalled and am asking for my previously held permissions (that were improperly removed) to be reinstated.

Again, we are trying to ensure that this is done correctly going forward and I apologize for the short term pain you are experiencing. Some combination of Gerrit-Managers and/or mediawiki-administrators (as proposed at the above talk page) should suffice for your work, yes? That's what I've been able to glean from what you've stated you're blocked on now. Is there anything else?

ema removed a subscriber: ema.Apr 8 2019, 11:11 AM
fgiunchedi triaged this task as Medium priority.Apr 9 2019, 8:34 AM

Can we add back both @Legoktm and @QChris to Gerrit Administrators? Seems like they were doing work that needs Administrator privilege and exercising their privilege judiciously. This was discussed in a higher-bandwidth convo with me, @greg, and @hashar which I think are the folks who needed to agree for this ticket to be resolved.

I would do this via the Gerrit interface; however, it seems like we're trying to use the gerritadmin ldap group now and I don't know if I'm able(?) to edit the LDAP group.

If someone with access to LDAP could add those folks (or point me to docs) that'd be great.

Mentioned in SAL (#wikimedia-operations) [2019-04-15T18:09:04Z] <mutante> LDAP - adding legoktm and qchris to gerritadmin group (T219086)

Dzahn added a subscriber: Dzahn.Apr 15 2019, 6:12 PM

@thcipriani Done. They have been added to the LDAP group.

docs are: https://wikitech.wikimedia.org/wiki/LDAP#Add_a_user_to_a_group (method 1)

[mwmaint1002:~] $ sudo modify-ldap-group gerritadmin

In addition to roots.. there is a special admin group called ldap-admins with sudo privileges for this and similar commands on mwmaint hosts.

Currently: members: [reedy, demon]

Dzahn closed this task as Resolved.Apr 15 2019, 6:14 PM
Dzahn claimed this task.
greg added a comment.Apr 15 2019, 6:15 PM

In addition to roots.. there is a special admin group called ldap-admins with sudo privileges for this and similar commands on mwmaint hosts.
Currently: members: [reedy, demon]

Should probably remove chad? Maybe add more people? (sorry, should be a different ticket....)

Dzahn added a comment.Apr 15 2019, 6:16 PM

Should probably remove chad? Maybe add more people? (sorry, should be a different ticket....)

I had the same thoughts, that's why i mentioned the members, and yes :)