Page MenuHomePhabricator

Add wmf LDAP group members into nda group, delete wmf group
Closed, DeclinedPublic

Description

The only distinctions (that I am aware of) between what these groups can do is that wmf gets some code review rights in gerrit (which it probably shouldn't) that nda does not, and wmf gets to administrate Jenkins (whereas nda does not). Volunteer vs. staff/contractor status should not be reflected in ACLs.
Users losing code review rights that they actually need due to this change should apply for project ownership the proper way.
See https://wikitech.wikimedia.org/wiki/LDAP_Groups#wmf_grants_access_to:

Event Timeline

Krenair created this task.Mar 13 2016, 7:23 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 13 2016, 7:23 PM
Krenair updated the task description. (Show Details)Mar 13 2016, 8:06 PM
Legoktm added a subscriber: Legoktm.

+1, sounds good. I don't see any reason why we wouldn't allow nda users to do stuff in jenkins.

fgiunchedi triaged this task as Normal priority.Apr 27 2016, 3:49 PM

This may have just been undermined by the use of the wmf group without the nda group in T138197: Staging area for the next version of the transparency report

I suggest we do it regardless.

jrbs added a subscriber: jrbs.Jun 20 2016, 2:24 PM
ori added a subscriber: ori.Jun 20 2016, 6:27 PM

This may have just been undermined by the use of the wmf group without the nda group in T138197: Staging area for the next version of the transparency report

The request from Legal for T138197: Staging area for the next version of the transparency report was that the staging area be accessible to staff only. The OED defines "undermine" as "to weaken, injure, destroy or ruin, surreptitiously or insidiously". Are you suggesting that there was something surreptitious or insidious about T138197, or did I misunderstand you?

I suggest we do it regardless.

A more appropriate (and polite) response would be "I suggest we check with Legal to see if it would be OK to extend access to trusted users that have signed an NDA." I just went ahead and asked, and will update the access controls if I get their permission.

hashar added a subscriber: hashar.Jun 20 2016, 6:37 PM

Regarding Jenkins, historically we solely had the wmf group. Then volunteers needed access and we added nda and Wikimedia Deutschland got added to wmde. wmf are allowed to Administer the system. wmde cant but have slightly more rights than nda.

For Jenkins the crazy security matrix is at https://integration.wikimedia.org/ci/configureSecurity/

Will probably want to dish it out and replace that with proper LDAP groups much like with did with the YAML bases modules/admin/data/data.yaml which has a contint-admins group.

Krenair added a comment.EditedJun 20 2016, 7:02 PM

This may have just been undermined by the use of the wmf group without the nda group in T138197: Staging area for the next version of the transparency report

The request from Legal for T138197: Staging area for the next version of the transparency report was that the staging area be accessible to staff only. The OED defines "undermine" as "to weaken, injure, destroy or ruin, surreptitiously or insidiously". Are you suggesting that there was something surreptitious or insidious about T138197, or did I misunderstand you?

That ticket does not look like a request from legal, and I do not think we should accept such requests if they will unfairly exclude volunteers. However in this case, without waiting for wider comment, you seem to have gone ahead and accepted the request without consensus. I wasn't looking at the dictionary definition of undermine, but other definitions suggest different understandings, this certainly wasn't the intended one. I wouldn't call it surreptitious or insidious.

I suggest we do it regardless.

A more appropriate (and polite) response would be "I suggest we check with Legal to see if it would be OK to extend access to trusted users that have signed an NDA."

If they asked to limit it to staff, they already would've considered this and ruled it out.

It also wasn't successfully limited to staff anyway because those groups include contractors and a non-contractor volunteer root (you can't really put data in the cluster and have it completely inaccessible to non-staff anyway).

ori removed a subscriber: ori.Jun 20 2016, 7:03 PM
Krenair added a subscriber: ori.Jun 20 2016, 7:03 PM
Krenair removed a subscriber: ori.

(apparently phabricator re-adds subscribers when you edit posts mentioning them)

elukey added a subscriber: elukey.Sep 7 2016, 1:30 PM
MoritzMuehlenhoff closed this task as Declined.Feb 17 2017, 10:12 AM

I don't think this is useful. With the current scheme we have the possibility to selectively grant some resources to staff only (as pointed out by Ori above) and the current consistency checks already ensure that group ownerships for staff/volunteers are in order.