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
.