Overview

In Gerrit, we assign permissions to groups of accounts. These groups can be provided by an external system such as LDAP, but Gerrit also has a group system built-in ("internal groups")

Starting from 2.16, these internal groups are fully stored in NoteDb.

A group is characterized by the following information:

  • list of members (accounts)

  • list of subgroups

  • properties

    • visibleToAll

    • group owner

Groups are keyed by the following unique identifiers:

  • GroupID, the former database key (a sequential number)

  • UUID, an opaque identifier. Internal groups use a 40 byte hex string as UUID

  • Name: Gerrit enforces that group names are unique

Storage format

Group data is stored in the All-Users repository. For each group, there is a ref, stored as a sharded UUID, e.g.

  refs/groups/de/deafbeefdeafbeefdeafbeefdeafbeefdeafbeef

The ref points to commits holding files. The files are

  • members, holding numeric account IDs of members, one per line

  • subgroups, holding group UUIDs of subgroups, one per line

  • group.config, holding further configuration.

The group.config file follows the following format

[group]
  name = <name of the group>
  id = 42
  visibleToAll = false
  description = <description of the group>
  groupOwnerUuid = <UUID of the owner group>

Gerrit updates the ref for a group based on REST API calls, and the commit log effectively forms an audit log which shows how group membership evolved over time.

To ensure uniqueness of the name, a separate ref refs/meta/group-names contains a notemap, ie. a map represented as a branch with a flat list of files.

The format of this map is as follows:

  • keys are the normal SHA-1 of the group name

  • values are blobs that look like

    [group]
  name = <name of the group>
  uuid = <hex UUID identifier of the group>

To ensure uniqueness of the sequential ID, the ID for each new group is taken from the sequence counter under refs/sequences/groups, which works analogously to the ones for accounts and changes.

Visibility

Group ownership together with visibleToAll determines visibility of the groups in the REST API.

Fetching a group ref is permitted to the group’s owners that also have READ permissions on the ref. For users that are not owners, the permissions on the ref are ignored. In addition, anyone with the Access Database capability can read all group refs. The refs/meta/group-names ref is visible only to users with the Access Database capability.

Pushing to group refs

Users can push changes to refs/for/refs/groups/*, but submit is rejected for changes which update group files (i.e. group.config, members, subgroups). It is possible for users to upload and submit changes on the named destination or named query files in a group ref. Pushes that bypass Gerrit should be avoided since the names, IDs and UUIDs must be internally consistent between all the branches involved. In addition, group references should not be created or deleted manually either. If you attempt any of these actions anyway, don’t forget to Index Group reindex the affected groups manually.

Replication

In a replicated setting (eg. backups and or primary/replica configurations), all refs in the All-Users project on primary nodes must be copied onto all replicas, including refs/groups/*, refs/meta/group-names and refs/sequences/groups.