Page MenuHomePhabricator

Service groups/"Manage members" does not handle nested service groups in the new LDAP scheme
Closed, ResolvedPublic

Description

On Tools, the service group jarry-common has as its members the user jarry1250 and the service groups grep and wikicup (https://wikitech.wikimedia.org/w/index.php?title=Special:NovaServiceGroup&action=managemembers&projectname=tools&servicegroupname=local-jarry-common&returnto=Special%3ANovaServiceGroup). However, even after removing and adding members to force a rewrite, the service group's LDAP records are:

dn: cn=tools.jarry-common,ou=servicegroups,dc=wikimedia,dc=org
objectClass: groupofnames
objectClass: posixgroup
objectClass: top
member: uid=jarry1250,ou=people,dc=wikimedia,dc=org
member: uid=local-wikicup,ou=people,ou=servicegroups,dc=wikimedia,dc=org
^^^^^^
member: uid=local-grep,ou=people,ou=servicegroups,dc=wikimedia,dc=org
^^^^^^
gidNumber: 51365
cn: tools.jarry-common
dn: cn=local-jarry-common,ou=groups,cn=tools,ou=projects,dc=wikimedia,dc=org
objectClass: groupofnames
objectClass: posixgroup
objectClass: top
member: uid=jarry1250,ou=people,dc=wikimedia,dc=org
member: uid=local-wikicup,ou=people,cn=tools,ou=projects,dc=wikimedia,dc=org
member: uid=local-grep,ou=people,cn=tools,ou=projects,dc=wikimedia,dc=org
gidNumber: 50775
cn: local-jarry-common

In eqiad, "getent group" queries the former structure which thus yields:

scfc@tools-login:~$ getent group tools.jarry-common
tools.jarry-common:*:51365:local-wikicup,local-grep,jarry1250
scfc@tools-login:~$ groups tools.grep
tools.grep : tools.grep
scfc@tools-login:~$

So tools.grep does not have access to tools.jarry-common's data.

Re fixing in general, the UI at the moment uses "local-", but in the shell users are presented with "tools.", this is confusing, and so this might be a good opportunity to switch the wiki UI to "tools.".

Re fixing in particular, the issue is not only "tools." vs. "local-", but the rest of the DN also is different (new LDAP):

member: uid=local-wikicup,ou=people,ou=servicegroups,dc=wikimedia,dc=org

but:

dn: cn=tools.wikicup,ou=servicegroups,dc=wikimedia,dc=org

("cn=" vs. "uid=", "ou=people" vs. none).

Affected service groups in Tools:

scfc@tools-login:~$ getent groupfgrep local-
tools.pb:*:51344:local-spbot,ireas,euku
tools.jarry-common:*:51365:local-wikicup,local-grep,jarry1250
tools.mp:*:51391:local-spbot,ireas,euku
tools.tsreports:*:51518:valhallasw,local-tsreports-dev,mzmcbride
tools.quentinv57-common:*:51561:local-quentinv57-bots,local-quentinv57-tools,local-irc-wmt,johnflewis,quentinv57
tools.shuaib-bot:*:51611:local-ameen,tahir,nadwi,local-tahir,ameen
tools.contropedia:*:51710:local-contropedia,ekborra,davids,boogheta
tools.orejasbot:*:51741:local-orejasbot,alan,mistrx
scfc@tools-login:~$

Version: unspecified
Severity: major

Details

Reference
bz62993

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 2:56 AM
bzimport set Reference to bz62993.

Thanks for writing this up Tim -- I wouldn't know where to start. The problem is also described by http://tools.wmflabs.org/wikicup/test.php , though I'm not sure that adds anything that you haven't covered above.

(Note that this behaviour was broken before the eqiad move, but Marc had kindly written a fix that should have (has?) come into effect on switchover. So while not technically a regression, this prevents the use of "secure" (770) sharing of files/libraries between tools, so it's still important to get fixed ASAP.

This is caused by Wikitech being a bit confused about old-style (local-X) vs new-style (project.X) group names, and unanticipated consequence of the migration being in progress.

I'll see about fixing this shortly.

This should be fixed... Tim, can you retest?

It appears fixed to me. I manually updated the affected tools via wikitech UI (removing $TOOL => $TOOL self-memberships in the process), and:

scfc@tools-login:~$ getent groupgrep '^tools\.'grep -v '^tools\.local-'sortfgrep local-
scfc@tools-login:~$