Skip to content

Pushes to Protected Branches in Private projects using Deploy Keys associated with users who are blocked and/or without direct membership in the project

Summary

With GitLab 13.10.3, Deploy Keys in private projects associated with users who are not members of the project and who are Blocked can not be used to push to a Protected Branch. This is unexpected and reproducible.

This issue is created on behalf of a customer who raised an emergency due to this unexpected behavior. GitLab team members with access to ZenDesk can learn more in the ticket. Prior to 13.6, this customer applied a patch to get Deploy Keys working as expected. We believe that the patch should not have been necessary after either 13.6 or 13.7. (See Inaccurate deploy keys passthrough.) A patch created during the emergency did not resolve the matter.

Additional information is available to GitLab team members with the appropriate access:

Steps to reproduce

These may be incomplete.

  1. A Private project exists and contains a Deploy Key owned/created by a user with an unknown role in the project
  2. remove the user owning the deploy key as a member of the project, block the user, then push with the deploy key -> Observe that the push fails
  3. unblock the user, add the user at Reporter, block user, then push -> Observe that the push fails
  4. unblock the user, confirm that the user still has Reporter , push -> Observe that the push succeeds

Example Project

What is the current bug behavior?

The git push operation is not successful:

remote: GitLab: You are not allowed to push code to this project.
To W.X.Y.Z:testme/test123.git
 ! [remote rejected] master -> master (pre-receive hook declined)

What is the expected correct behavior?

The git push operation should succeed.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

The following patch was provided:

diff --git a/lib/gitlab/git_access.rb b/lib/gitlab/git_access.rb
index c5ca46827cb..6e3e8af7252 100644
--- a/lib/gitlab/git_access.rb
+++ b/lib/gitlab/git_access.rb
@@ -319,6 +319,9 @@ def user_can_push?
     end
     def check_change_access!
+      # Deploy keys with write access can push anything
+      return if deploy_key?
+
       if changes == ANY
         can_push = deploy_key? ||
                    user_can_push? ||
  • Modifications were required to get it to work in the customer's environment but not in our testing environment.
  • The modified patch did not lead to the expected results in the customer's environment once it was successfully applied.

Solution

After the discussions (See thread and thread), we determined that we should not de-couple deploy keys from users. We will improve our documentation to make this situation clear and add recommendation of how to resolve this issue.

Edited by Kevin Chu