653668 - Create a user group for web localizers to grant webby permissions to and fill it from ldap

Status: RESOLVED WONTFIX

(Webtools Graveyard :: Elmo, defect, P3)

Description

[Axel Hecht [:Pike]]

We need a user group for web localizers, to grant them permission to opt in to web projects.

We should fill that group with folks from the @localizers ldap group, if I only knew the query.

Created WebLocalizers with the right permission already.

Comment 1

[Axel Hecht [:Pike]]

Justin, I see that you resolved a bunch of bugs to grant localizers svn permissions, can you help us out here? What exactly are you doing, and what is our infra checking for? Thanks.

Comment 2

[Axel Hecht [:Pike]]

Probably depends on a better ldap hook from bug 566468.

Also, we still need to know what data we're actually looking for. Justin?

Comment 3

[Axel Hecht [:Pike]]

We have a manually maintained group for now, so unsetting severity/priority.

Comment 4

[Staś Małolepszy :stas]

Here's what I learned from XioNoX:

- hg localizers have scm_level_1 and scm_l10n, as per bug 549873,
- svn localizers only have svn_mozilla,
- all svn localizers are in @localizers group in svn, which is defined by a config file for the svn server.

We need to translate the @localizers group into LDAP bits.

I see two options:

1) reuse scm_l10n for SVN, and add it to all users from the @localizers list.  It is my understanding that these users don't have scm_level_1 (but I haven't checked all of them), so by granting them scm_l10n, we would be giving them l10n hg access.

2) create a new bit for the SVN localizers and grant it to all users from the @localizers list.  this can be tricky, as XioNoX is currently the only person handling LDAP (after Aravind left) and, as he has put it, he is still learning :)

Gerv, would you be fine with option 1)?

Comment 5

[Axel Hecht [:Pike]]

Localizers have L1 and scm_l10n by design, I doubt that we check for both groups to grant access to hg. The L1 controls the user repos, scm_l10n access to the l10n repos.

I wouldn't want to overload the scm_l10n group by controlling both svn and hg. They're technically different enough to require different vouchings.

Thus I'd clearly prefer 2) here.

Comment 6

[Gervase Markham [:gerv]]

(In reply to comment #5)
> I wouldn't want to overload the scm_l10n group by controlling both svn and
> hg. They're technically different enough to require different vouchings.

Can you explain that in more detail? Because using the scm_l10n group to allow localizers access to whatever SCM permissions they need to do their job (i.e. Stas's option 1) seems like exactly the right thing to me.

Gerv

Comment 7

[Axel Hecht [:Pike]]

Generally speaking, we've created an svn account for anyone with an hg account, but not the other way around. Which corresponds to "the privs they need to complete the job", product localizers need to do some web pages to complete Firefox, while localizers of web projects don't need write access to Firefox or Thunderbird localizations.

Comment 8

[Gervase Markham [:gerv]]

They may not need that write access, but the question is: are they going to actively abuse it? Is some localizer who was only working in SVN going to start checking in to random Hg localizations? If they are going to behave that badly, why do we even trust them with SVN access?

The question is: are SCM permissions bits about stopping people technically breaking things, or are they about restraining evildoers? I don't think it's the former; if people break stuff (or might in the future), we fix that by education. If it's the latter, then we already trust these people to check into SVN, and if they also have the ability to check into Hg, that shouldn't be a problem.

Comment 9

[Robert Kaiser]

AFAIK, the intent of creating just 3 levels of repository access was to not have a plethora of detailed permission bits floating around, esp. as all those people have signed our committer agreement anyhow and we deemed social control working well enough against abuse, which we haven't really seen yet.
It doesn't mean that everyone needs to have an (active) account with all the SCMs we have, in fact, we keep deactivating accounts that haven't been used for long enough.

Given that, I think one _permission_ bit for L10n ought to be enough, if people have an svn account or not is a different matter, we only should open/activate those for people who actually need them.

Comment 10

[Staś Małolepszy :stas]

I agree with Gerv.  Following the logic of introducing new bits to control access to HG vs. access to SVN, it would seem fitting to assume that an SVN localizer with access to website1 should not have access to website2.  I don't think we want to do this.

Similarly, one could argue that today's situation in which a French HG localizer can in fact freely commit to a German HG repository is dangerous.  Yet, we haven't seen abuse that one would expect.

I think that trust is much more powerful than LDAP bits :)

I also think that it's a bit weird that the current SVN localizers don't have scm_level_1.  This leaves them in a no man's land without any level, and yet they have access to some parts of SVN.

Could we just unify this and give all HG and SVN localizers alike the following three bits: 

- scm_level_1, 
- scm_l10n, 
- svn_mozilla (+ @localizers in SVN)?

Comment 11

[Axel Hecht [:Pike]]

That makes me wonder why we would have levels at all? The arguments here leave little room to breathe for level 3, do they? Sounds more like a discussion for .governance at this point than a string of bug comments, in particular in this bug.

To frame the discussion with some data:

There are 94 accounts with both hg and svn, 144 hg only, and 63 svn only.

The hg-only ones include a few dead ends, our build accounts, and a host of more or less active helpers.
svn-only includes the verbatim account (which has an ssh-key in ldap, fwiw)

It seems that the lists aren't really in sync with the actually used accounts, too. And only a third of our accounts are actually set up in the way that is proposed here.

Comment 12

[Gervase Markham [:gerv]]

pike: Brendan has already indicated a desire to do away with Level 3. That's not something we've got around to implementing yet. Still, it seems the project is moving in the direction of more trust, because we have more visibility over checkins.

As for dormant accounts, we also have a process of disabling those - those inactive for six months will get disabled. If that isn't happening for some reason, we should look into that.

Gerv

Comment 13

[Axel Hecht [:Pike]]

Last I heard, @localizers is a plain text file and not an ldap group. Thus marking this WONTFIX, as we can't feed our group on elmo from a non-existent ldap group.