GitLab

Created by: jcockhren

I think I've been pointed a potential cause of the issue (at least for me). I've tried all possible solutions listed in thread #4730 (closed)

4 days ago when I did the normal monthly upgrade, I also disabled the LDAP auth. I did logout and log back in manually for the user under question however that does not solve the problem. Preconditions

• Consider the a user that has a key_id of 20 that previously had access to the repository. AND also could log into the web interface via normal creds and LDAP auth.
• ldap is disabled

The git pull command, gitlab-shell spits out this:

ERROR -- : API call <GET https://gitlab.example.com//api/v3/internal/allowed?key_id=20&action=git-upload-pack&ref=_any&project=web/examplecom> failed: 500 => <{"message"=>"500 Internal Server Error"}>.

I can reproduce this by doing a curl to the API call URL. like so:

curl 'https://gitlab.example.com//api/v3/internal/allowed?key_id=20&action=git-upload-pack&ref=_any&project=web/examplecom'

Tested the likelihood that the problem is isolated within the gitlab-shell by making the API call with a user I know doesn't have access to a repo (key_id 3 does not suppose to have access)

curl 'https://gitlab.example.com//api/v3/internal/allowed?key_id=3&action=git-upload-pack&ref=_any&project=web/examplecom'

When ran the result is correct: false

Then curling a repo that key_id 3 works the result is: true.

When trying to original key_id=20 the production.log shows:

Net::LDAP::LdapError (No such address or other socket error.):
  /home/git/gitlabhq/vendor/bundle/ruby/1.9.1/gems/net-ldap-0.3.1/lib/net/ldap.rb:1110:in `rescue in initialize'
  /home/git/gitlabhq/vendor/bundle/ruby/1.9.1/gems/net-ldap-0.3.1/lib/net/ldap.rb:1107:in `initialize'
  /home/git/gitlabhq/vendor/bundle/ruby/1.9.1/gems/net-ldap-0.3.1/lib/net/ldap.rb:634:in `new'
  /home/git/gitlabhq/vendor/bundle/ruby/1.9.
[... cut out ... ]
  /home/git/gitlabhq/lib/gitlab/ldap/user.rb:81:in `blocked?'
  /home/git/gitlabhq/lib/api/internal.rb:38:in `block (2 levels) in <class:Internal>'

So let's take a look at line 38 in the api/internal.rb:

return false if user.ldap_user? && Gitlab::LDAP::User.blocked?(user.extern_uid)

Now, note that ldap enabled: false

So it screams to me that if a user was previously authenticated by LDAP, it checks if the user is blocked, which in turns requires a call to the host variable thats listed in the gitlab config. See: https://github.com/gitlabhq/gitlabhq/blob/master/lib/gitlab/ldap/user.rb#L79

It should check if the ldap is still enabled. This would definitely happen during the happen during the cases of the LDAP server being down (and therefore turned off) or during testing ldap usage.

if Gitlab.config.ldap.enabled
    return false if user.ldap_user? && Gitlab::LDAP::User.blocked?(user.extern_uid)
end

Would be the easiest change.