tree 81d483ea3348eb3607333375bc9b4ae43c6c5fd4
parent 33ce3f0ad6d6f17b731887517938562469b693b3
author Patrick Hiesel <hiesel@google.com> 1604323854 +0100
committer Patrick Hiesel <hiesel@google.com> 1604668421 +0100

Make PermissionBackend#ForRef authoritative

This change fixes a misconception that leads to data being accessible
through Gerrit APIs that should be locked down.

Gerrit had two components for determining if a Git ref is visible to a
user: (Default)RefFilter and PermissionBackend#ForRef (ex RefControl).
The former was always capable of providing correct results for all refs.
The latter only had logic to decide if a Git ref is visible according to
the Gerrit READ permissions. This includes all refs under refs/heads as
well as any other ref that isn't a database ref or a Git tag. This
component was unware of Git tags and database references. Hence, when
asked for a database reference such as refs/changes/xx/yyyyxx/meta the
logic would allow access if the user has READ permissions on any of the
ref prefixes, such as the default "read refs/* Anonymous Users".

That is problematic, because it bypasses documented behavior [1] where
a user should only have access to a change if they can see the destination
ref. The same goes for other database references.

This change fixes the problem. It is intentionally kept to a minimally
invasive code change so that it's easier to backport it.

Add tests to assert the correct behavior. These tests would fail before
this fix. We have included them in this change to be able to backport
just a single commit.

[1] https://gerrit-review.googlesource.com/Documentation/access-control.html

Change-Id: Ice3a756cf573dd9b38e3f198ccc44899ccf65f75