Fix incorrect actor used to check permissions for SSH receive-pack
During a SSH receive-pack request (e.g. git push), gitlab-shell was
incorrectly using the user returned by the /internal/allowed API
endpoint to make an SSHReceivePack RPC call. This caused a number of
problems with deploy keys with write access:
-
Keys that were generated by a blocked user would be denied the ability to write--but they could still read!
-
Keys that were generated by user that did not have write access to the project would also be denied.
GitLab 12.4 removed the Ruby implementation of gitlab-shell in favor of
the Golang implementation, and these implementations worked slightly
differently. In
https://gitlab.com/gitlab-org/gitlab-shell/blob/v10.1.0/lib/gitlab_shell.rb#68,
the Ruby implementation would always use @who (e.g. key-123), but in
gitlab-shell v10.2.0 the Go implementation would always use the user
from the API response (https://gitlab.com/gitlab-org/gitlab-shell/-/blob/v10.2.0/go/internal/command/receivepack/gitalycall.go#L25).
There was an inconsistency here with reads and writes. Deploy keys that were generated by a blocked user could still read the repository but not write to them.
Reads did not have this issue because the user/deploy key is never passed to Gitaly for additional permission checks. Writes need this information for the pre-receive to check access to protected branches, push rules, etc.
Relates to #479 (closed)