439140 - Need permissions check hook for hg repos

Status: RESOLVED FIXED

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

Description

[Axel Hecht [:Pike]]

Lots of folks talk about a hook for hg to check whether a particular user has access to a particular repository or not.

This affects at least users with write access for incubator repos, and localizers.

Dan Schafer is writing a python class to check ldap in bug 435975, which we might be able to reuse.

Not sure how much of that we actually store in ldap, and how. Reed, can you enlighten us at least on the /l10n vs /cvsroot part when it comes down to current write access to cvs?

No idea how this is related to bug 353463 or not.

Comment 1

[Benjamin Smedberg]

We already have such a hook, which can limit particular repositories to particular LDAP groups. Is that insufficient? Is this a meta-request, or a request for some particular repository?

Comment 2

[Axel Hecht [:Pike]]

Oh, I understood reed to say that we don't.

Where are the documents that explain what's set up on hg, and what's not?

Comment 3

[Reed Loden [:reed]]

(In reply to comment #2)
> Oh, I understood reed to say that we don't.

I said we aren't using any ACLs on Hg besides cvs-trunk-mirror now.

Comment 4

[Axel Hecht [:Pike]]

Do those ACLs have anything to do with a hook checking for the stuff we use to determine whether a user has access to the l10n or cvsroot cvs repositories?

In other words: I don't really care what needs to be done, but localizers shouldn't get generic write privs. Fix that.

Comment 5

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to comment #1)
> We already have such a hook, which can limit particular repositories to
> particular LDAP groups. Is that insufficient? 

(In reply to comment #4)
> In other words: I don't really care what needs to be done, but localizers
> shouldn't get generic write privs. Fix that.


Is there anything left to do here?
Is this even a RelEng bug or should this be reassigned to IT as part of general hg setup work?

Comment 6

[Benjamin Smedberg]

This should never have been releng.

Aravind, I believe the current summary of this bug should be:

* Need to give localizers access to hg.mozilla.org
* Need to prevent localizers from pushing to mozilla-central and the other "main" repos

I propose that we create an LDAP group for mozilla-central-committers consisting of everyone who currently has "main" cvs commit access and add an ACL check to the main repos (the non-user repos) for that group. Does that make sense?

Comment 7

[Daniel Chen]

Attachment: unix group-like acl permissions for mercurial

Comment 8

[Daniel Chen]

I've slightly modified the acl extension for mercurial to support POSIX groups as well as what I call "virtual groups". Access control is handled in the hgrc of a repository, and is per file. Because the extension gets authn information from the system, we get ldap integration for free.

Comment 9

[Daniel Chen]

Attachment: Sample hgrc

This is a sample hgrc with comments that shows you how to use the acl extension.

Comment 10

[Axel Hecht [:Pike]]

How would the group be set for a particular file when a user is in multiple groups? I'm thinking about folks like me, who likely should end up with write permissions to several if not many different "permission islands", for regular write access in mozilla-central and peer write access on l10n repositories.

Comment 11

[Daniel Chen]

CC-ing vlad and brendan per aravind's request

Comment 12

[Daniel Chen]

(In reply to comment #10)
> How would the group be set for a particular file when a user is in multiple
> groups? I'm thinking about folks like me, who likely should end up with write
> permissions to several if not many different "permission islands", for regular
> write access in mozilla-central and peer write access on l10n repositories.

A file is not restricted to a single group (or virtual group). You can specify multiple groups that have access to a file. In ambiguous cases, the most restrictive set of permissions is given (i.e. Suppose a user is in groups B and C, but a file is by allowed to B and denied to C; this means that the user cannot access the file).

Comment 13

[Axel Hecht [:Pike]]

To clarify, this would implement permission checks not by file permissions as Aravind suggested in http://groups.google.com/group/mozilla.dev.planning/browse_frm/thread/9864460d1009e0f0#? That might have gotten me confused.

Comment 14

[Aravind Gottipati [:aravind]]

I did post that.  However, I figured folks would eventually need the functionality to control access within a repo.  So I had dchen wite this acl extension.  For now we will only implement group (ldap) controls per repo.  This acl is posted here for your review - if we do end up using it at some point.

Comment 15

[Aravind Gottipati [:aravind]]

Okay, I believe this is now ready.  I now have a LDAP group called hg_mozsrc.  I have changed mozilla-central to use this group.  We can now create l10n repos as needed and make the repo group hg_l10n.

All l10n commiters that need to push to mercurial should be in this group (hg_l10n) along with the hg_mozilla group.

Currently hg_mozsrc pretty much contains everyone with mercurial access, but we can trim that over time.

The l10n repo structure is still up for debate.  If we go with one l10n repo, and later decide that we want to restrict access within this repo based on that path, we can use dchen's ACL script.

The other way to is create a l10n top directory and create multiple l10n repos underneath - one per locale.  Its your call on how you want to handle this.

Once you decide on a layout, please file a separate bug for that.

(I think having a top level l10n repo, and using dchen's script is cleaner.)

Comment 16

[Axel Hecht [:Pike]]

Filed bug 449199 on the l10n repos. We're not going to go for a single l10n repo, as that'd require all localizers to constantly merge all other locales in, which would just be an annoyance. Bug 449196 is for the actual access for localizers.