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
0532fb876c