Skip to content

Gitlab.Database.Grant should use SHOW GRANTS for MySQL, not query the MySQL user table

Discussed in IRC 9/25/2017 at 4:55PM PST, was asked to make an issue.

Summary

The Grant class performs SELECT query on mysql.user in order to validate database user has TRIGGER permission, which is unsafe, as it requires global permissions to access the mysql.user table. Grant should instead use SHOW GRANTS, which doesn't need special permissions when querying the current user's permissionset.

Steps to reproduce

  1. GRANT ALL PERMISSIONS ON gitlabhq_production.* ON gitlab@localhost; (With no global permissions or GRANT)
  2. Upgrade GitLab 9.4 to 9.5 using MySQL or MariaDB as DBMS.
  3. Run sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production

Example Project

N/A

What is the current bug behavior?

GitLab raises a set of errors relating to being unable to SHOW FULL FIELDS FROM mysql.user (paraphrased), then demands global superuser-level permissions to continue.

Full error log: https://hastebin.com/fonafilaja.coffeescript

What is the expected correct behavior?

GitLab uses SHOW GRANTS instead, and completes the permission check happily without permissions to mysql.User.

Relevant logs and/or screenshots

Output of checks

gitlab:env:info 
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production

System information
System:         Debian 9.1
Current User:   git
Using RVM:      no
Ruby Version:   2.3.3p222
Gem Version:    2.6.10
Bundler Version:1.15.4
Rake Version:   12.0.0
Redis Version:  3.2.6
Git Version:    2.11.0
Sidekiq Version:5.0.4
Go Version:     go1.8.3 linux/amd64


GitLab information
Version:        9.5.5
Revision:       3cf5eba3d4
Directory:      /home/git/gitlab
DB Adapter:     mysql2
URL:            http://git.nexisonline.net
HTTP Clone URL: http://git.nexisonline.net/some-group/some-project.git
SSH Clone URL:  git@git.nexisonline.net:some-group/some-project.git
Using LDAP:     no
Using Omniauth: no


GitLab Shell
Version:        5.8.0
Repository storage paths:
  • default: /home/git/repositories Hooks: /home/git/gitlab-shell/hooks Git: /usr/bin/git

NOTE: Failed during upgrade, so this will not be happy.

gitlab:check 
root@dedi:/home/git/gitlab# sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true
Checking GitLab Shell ...

GitLab Shell version >= 5.8.0 ? ... OK (5.8.0)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:root, or git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...
1/1 ... ok
1/2 ... ok
1/4 ... ok
1/5 ... ok
1/7 ... ok
2/11 ... ok
2/13 ... ok
1/15 ... ok
1/16 ... ok
1/17 ... ok
1/18 ... ok
1/19 ... ok
1/20 ... ok
1/21 ... ok
1/22 ... ok
1/23 ... ok
1/24 ... ok
1/25 ... ok
16/26 ... ok
1/27 ... ok
1/28 ... ok
1/29 ... ok
1/30 ... ok
1/31 ... ok
1/32 ... ok
1/33 ... ok
20/34 ... ok
1/35 ... repository is empty
19/36 ... ok
1/37 ... ok
1/38 ... ok
2/39 ... repository is empty
2/40 ... ok
29/41 ... repository is empty
2/42 ... ok
1/43 ... ok
1/44 ... ok
35/45 ... ok
36/46 ... repository is empty
Running /home/git/gitlab-shell/bin/check
Check GitLab API access: FAILED. code: 502
gitlab-shell self-check failed
Try fixing it:
Make sure GitLab is running;
Check the gitlab-shell configuration file:
sudo -u git -H editor /home/git/gitlab-shell/config.yml
Please fix the error above and rerun the checks.


Checking GitLab Shell ... Finished


Checking Sidekiq ...


Running? ... no
Try fixing it:
sudo -u git -H RAILS_ENV=production bin/background_jobs start
For more information see:
doc/install/installation.md in section "Install Init Script"
see log/sidekiq.log for possible errors
Please fix the error above and rerun the checks.


Checking Sidekiq ... Finished


Checking Reply by email ...


Reply by email is disabled in config/gitlab.yml


Checking Reply by email ... Finished


Checking LDAP ...


LDAP is disabled in config/gitlab.yml


Checking LDAP ... Finished


Checking GitLab ...


Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... yes
Init script up-to-date? ... yes
Projects have namespace: ...
1/1 ... yes
1/2 ... yes
1/4 ... yes
1/5 ... yes
1/7 ... yes
2/11 ... yes
2/13 ... yes
1/15 ... yes
1/16 ... yes
1/17 ... yes
1/18 ... yes
1/19 ... yes
1/20 ... yes
1/21 ... yes
1/22 ... yes
1/23 ... yes
1/24 ... yes
1/25 ... yes
16/26 ... yes
1/27 ... yes
1/28 ... yes
1/29 ... yes
1/30 ... yes
1/31 ... yes
1/32 ... yes
1/33 ... yes
20/34 ... yes
1/35 ... yes
19/36 ... yes
1/37 ... yes
1/38 ... yes
2/39 ... yes
2/40 ... yes
29/41 ... yes
2/42 ... yes
1/43 ... yes
1/44 ... yes
35/45 ... yes
36/46 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.3 ? ... yes (2.3.3)
Git version >= 2.7.3 ? ... yes (2.11.0)
Active users: ... 30


Checking GitLab ... Finished

Possible fixes

After talking with some guys in the #gitlab IRC channel, we discovered that the Grant class appears to be the culprit.

A possible workaround is to temporarily grant superuser permissions, and then drop permissions after migrations are complete. This makes me antsy, since my users are 4channers.

If I knew much about Ruby, I'd be happy to help, but I have my own responsibilities going on.

Edited by Rob Nelson