Configure Access Rights (ACLs) for a Repo
GitCentric implements a group-based ACLs security model derived from Gerrit Code Review. This is a powerful tool for defining who can do what with Git repositories under GitCentric control. You will need to have a solid understanding of these group-based ACLs and do some planning before implementing them, so be sure to first read the following section:
GitCentric Group-Based ACLs on page 10, and the
Gerrit Code Review documentation for details.
General Procedure for Setting ACLs
Use the following general procedure for settings ACLs on your repos.
1. Click the
Administration button, then click the
Repositories menu to display the Repositories page. (See
Chapter 5 Administration for reference information.)
2. Click the repository you want to configure. Selecting All-Projects will cause all other repositories to inherit whatever ACLs you apply. (Note: Only the All-Projects system-defined repo has a "Global Capabilities" section with an Administrate Server permission which gives Administrators broad powers across all repos. Be extremely careful when editing this permission.)
3. On the Repositories page, click the
Access button. (Reference information is a available at
Access on page 68.)
4. Use the
Rights Inherit From: link to specify the repository from which you want the new repository to inherit its access settings. (By default, all repositories inherit access rights from the system-defined “All-Projects”. You can create a parent-only repository to easily apply settings such as this to all child repositories. See
Create a Repository for GitCentric on page 29 for more information.)
5. Click Edit, then Add Reference. In the Reference field, you can accept the default value (refs/heads/*) to apply the access setting to all branches in repository, or modify it to apply to a specific branch. Specifying refs/* applies the ACL to everything in the repo.
6. Select the permission that you want to apply to this repository from the drop-down menu.
7. After selecting the permission, complete the Group Name field for whom this permission applies in the this repository. The field supports type-ahead, so, for instance, entering “R” will provide “Registered Users” as a possible completion.
8. Optionally enter a commit message. An admin user can view this when performing a
git log refs/meta/config command on the repository.
9. When done, click the Save Changes button.
Configuring ACLs for Code Review
Part of enabling the GitCentric’s optional Gerrit Code Review functionality involves setting ACLs for Git references as shown in the following table:
Most of these ACLs are set automatically for the All-Projects repository when you install GitCentric. There are slight differences based on whether you installed GitCentric 2013.3 for the first time, or you upgraded to GitCentric 2013.3 from an existing installation. If you:
• Installed GitCentric 2013.3 for the first time, all ACLs listed in the preceding table are set as the default for the system-defined "All-Projects" repository. Any repository that inherits rights from "All-Projects" is also configured to support code review.
• Upgraded to GitCentric 2013.3 from a previous release and you are currently using Gerrit Code Review, you will need to manually set the Submit permission for refs/* as shown in the preceding table. All other permissions (Forge Author Identity, Push, and Label Code-Review) were set as the default for All-Projects when you installed GitCentric.
If you upgraded from a previous release and are not currently using Gerrit Code Review and now wish to, you must manually set all the ACLs listed in the preceding table.
Once the ACLs are set, all that remains to enable code review is for your users to configure their clones to support code review. See
Configure the Clone for Code Review (Optional) on page 20 for more information.
Additional Considerations for ACLs
There is no one set of ACLs that are appropriate for every installation; you must analyze the needs of your specific installation and adjust the default ACLs as necessary. See the
Access Controls topic in the Gerrit Code Review documentation, specifically the section labeled "Examples of typical roles in a project" for suggestions about setting Gerrit Code Review ACLs.
The remaining topics in this section describe other considerations to evaluate when enabling code review.
Label Verified
The "Verified" category is generally intended to be used in continuous integration environments where Gerrit Code Review is integrated with Hudson or Jenkins. Typically, the vote for this category is set to +1 by the integration tool indicating that it was able to compile and run tests on the change, allowing the change to be submitted. If you do not have a continuous integration environment, you can either disable the "Verified" category, or configure the "Label Verified" ACL in GitCentric to allow users to manually specify a vote via the Gerrit Code Review GUI. The ACL to allow manual voting for the "Verified" category is shown in the following table.
Note: Specifying the "Label Verified" ACL this way permits any Registered User to approve and submit any code review change. This may be fine for testing, but you must tighten up ACLs for production.
Allowing users to set "Label Verified" manually could be redundant with the "Label Code-Review" ACL. These three approaches to configuring the "Verified" category are summarized below in the order of desirability:
1. Configure Verify with Hudson or Jenkins for automated, Continuous Integration (CI).
2. Disable Verify completely.
3. Configure the "Label Verified" ACL in GitCentric (as shown in the preceding table) to allow users to vote manually in the Gerrit Code Review UI.
If you choose the third option for testing purposes, you should consider either reconfiguring it for automated CI, or disabling it completely, prior to putting GitCentric into production mode.
Configuring "Verify" for Continuous Integration
With Hudson or Jenkins, you would typically set the Label Verified permission for the "Non-interactive users" group. See the Hudson, Jenkins, and/or Gerrit Code Review documentation for details about configuring a Continuous Integration environment.
Disabling "Verify"
If you are not using Jenkins/Hudson continuous integration, you can disable the "Verified" requirement in Gerrit Code Review with the gerrit gsql command:
ssh -p 29418 <your_server.com> gerrit gsql
DELETE FROM approval_categories WHERE category_id = 'VRIF';
DELETE FROM approval_category_values WHERE category_id = 'VRIF';
Configuring GitCentric ACLs for Direct Push
If you do not wish to use GitCentric’s optional Gerrit Code Review functionality, you must modify the default ACLs as follows. (These are simply minimal suggestions. You must analyze your site requirements and customize these settings as appropriate for your specific site.)
1. Change the setting for the "Push" permission for refs/for/refs/* to BLOCK.
2. Add the "Push" permission for refs/* and set it to ALLOW.
3. Add the "Push Merge Commits" permission to refs/* and set it to ALLOW.
You must also have your users adjust the Git config file in each of their clones to remove the following line:
push = refs/heads/*:refs/for/*