561326 - Make SVN authz file match new Commit Access Policy

Status: RESOLVED WONTFIX

(mozilla.org Graveyard :: Server Operations, task)

Description

[Gervase Markham [:gerv]]

It may be that this has already been done, but if not, here is a bug to track the work.

The new Commit Access Policy means that people with level 2 SCM access can check in anywhere in SVN except for a given list of paths where additional approval is needed. See http://www.mozilla.org/hacking/commit-access-policy/ - Level 1A - for the list of exceptions.

The SVN authz file needs to reflect this. As far as I know, it currently has a large number of different groups with different permissions for different areas. That should be simplified down to the list given in the policy.

It should be that the current file already has enough information to know who should be approved to check in for each one of the individual exception paths. Where it does not, please let me know which path it is and I will contact the owner of that path for a list.

Gerv

Comment 1

[Aravind Gottipati [:aravind]]

This wasn't done last night, will work on it today.

Comment 2

[Gervase Markham [:gerv]]

Aravind: ping?

Gerv

Comment 3

[Aravind Gottipati [:aravind]]

I am e-mailing you the current authz file (from the subversion repo).  It has a much finer access control than the one laid out in the commit policy.  Please go through the file, and lay out for me who loses access to what, which paths we are opening up etc.

Also, you might want to clear it up with the webdev folks and others..

Comment 4

[Gervase Markham [:gerv]]

Firstly, you need to check that everyone listed in that file has level 2 access. Can you give me a list of everyone who is named in the authz file who doesn't? On reading it, I suspect there are some localizers in this boat, and so we'll need to keep the @localizers group as well.

This is my current idea of how I would lay out the authz file. (Don't do this yet; I need the list above first!)

As now, anyone can read everything by default. Build team and sysadmins have global rw.

Anyone with level 2 has rw everywhere except the following places.

So:

[/]
* = r
@level2 = rw
@build-team = rw
@sysadmins = rw

I would have a separate permissions list for each of the following paths, which are the ones nominated by the community and defined in the policy. Membership of that list would be worked out by looking at who has access now, and copying that. Specifically:

/projects/mozilla.org/trunk                     
  From /projects/mozilla.org/trunk, line 662
/projects/mozilla.com/tags/production           
  From /projects/mozilla.com/tags, line 658, +
       /projects/mozilla.com/tags/production, line 674
/projects/mozilla-europe.org/tags/production
  From /projects/mozilla-europe.org, line 580
/projects/crm/tags/production                   
  From /projects/crm, line 219
/projects/services.mozilla.com/tags/production  
  From /projects/services.mozilla.com/tags, line 1294
/projects/publicsuffix.org/trunk                
  From /projects/publicsuffix.org, line 559
/projects/static.mozilla.com/trunk              
  From /projects/static.mozilla.com/trunk, line 1283
/projects/getfirebug.com/tags/production        
  From /projects/getfirebug.com, line 304
/projects/mozillaonline.com/tags/production     
  From /projects/mozillaonline.com, line 241
/projects/spreadfirefox.com/affiliates_buttons/tags/production
  From /projects/spreadfirefox.com, line 471

Also the following, which I suspect needs to be restricted:

/projects/google_snippets
  From /projects/google_snippets, line 315 +
       /projects/google_snippets/trunk/static (line 325)

I believe each of these paths would need to begin:

[/projects/crm/tags/production]
@level2 = r
...

in order to reset the level 2 global permission. (Note that we don't reset build-team or sysadmins.)

These changes _should_ replicate the permissions currently existing for all the listed paths, and open permissions up for all other paths. In other words, the goal is that no-one should _lose_ access through these changes. If, while you are making them, it looks like that's not going to be true, stop and ask.

Gerv

Comment 5

[Aravind Gottipati [:aravind]]

(In reply to comment #4)

> Firstly, you need to check that everyone listed in that file has level 2
> access. Can you give me a list of everyone who is named in the authz file who
> doesn't? On reading it, I suspect there are some localizers in this boat, and
> so we'll need to keep the @localizers group as well.
> 

so hg commit access levels don't translate into svn very well.. (at least not the way svn acls are implemented right now).  Here is the problem.

svn is just one giant repo, but we have multiple repos in our hg server.
hg access is currently all based on unix groups.
svn access is based on the authz file (that I sent you).

granting someone a level X hg account means that they have scm_level_X and all levels below X (scm_level_$Y where $Y < X).  This means nothing to svn, since its all just in that one flat file.

I can't think of a sane way to keep the two (svns access list) and scm access levels in sync.  I am open to suggestions you or others might have to cope with this..

I can go through the authz files and check if they have scm_level_X bits turned on and get you that list (but like I explained above, it won't mean anything for svn even if we enable those bits in LDAP).  Let me know if you still want that list.

Comment 6

[Gervase Markham [:gerv]]

So it looks like we are having another discussion at the moment on the right way to do commit access :-| Brendan has asked that we revisit some issues. So let's not make any changes for now, untilt he dust settles. When it does, I'll get back to you.

Gerv