Administrator can inadvertently brick user project creation ability

HackerOne report #1017258 by godzilla74 on 2020-10-23, assigned to @ankelly:

Report

Summary

If a user has project limits imposed by an administrator and has met the cap, there does not appear to be a way to create additional projects if the administrator is the one performing the housekeeping.

Steps to reproduce

As an administrator in one browser window, set a 'projects limit' for the user by editing their profile (http://<gitlab instance>/admin/users/<username>/edit) or 'Admin area > Overview > Users > Edit'

As a user in a different session/browser window, create enough projects that will eventually meet the project count threshold (2 in our case). Notice, that one the limit is met, the 'New Project' button no longer shows in the upper right for the user:

-. Back to the administrator profile, delete the projects associated with the user in question (Godzilla1 in our case):

As the user, click the Gitlab Logo in the upper left. This should take you back to the 'Welcome to Gitlab' page since you no longer have any projects. You'll find here that the 'Create a project' section is not clickable (the upper left box in the grouping):

What is the current bug behavior?

The only apparent way a user can now create a new project is to make it within an existing group (if they have the access to one), or to create a new group to do this (again, if they have the access to do so in their profile). This is not ideal.

A less apparent option (albeit it doesn't work) is for the user to visit their profile page to create a new project (http://<gitlab instance>/users/<username>/projects).

However, in my testing, it seemed that the imposed limit was still in place:

The only way I was able to make projects again was to increase the user's 'project limit' count to be > 2:

A recording worth 297 words ... and 7 images ...

I'm trying the video recording feature out for the first time. Here are some things to note:

The left browser window in the administrator (imposing the project limit)
The right browser window is the normal user (with the imposed project limit)

recording-1603479483580.webm

What is the expected correct behavior?

The expected behavior when project limits and housekeeping is performed as an administrator should be the same as if housekeeping was performed by the project owner (the user). In my testing as a user, after meeting the project limit threshold, then deleting a project, I was able to make a new one to re-meet the imposed project limit.

Results of GitLab environment info

System information  
System:         Ubuntu 18.04  
Proxy:          no  
Current User:   git  
Using RVM:      no  
Ruby Version:   2.6.6p146  
Gem Version:    2.7.10  
Bundler Version:1.17.3  
Rake Version:   12.3.3  
Redis Version:  5.0.9  
Git Version:    2.28.0  
Sidekiq Version:5.2.9  
Go Version:     unknown

GitLab information  
Version:        13.4.4-ee  
Revision:       4196ccb4738  
Directory:      /opt/gitlab/embedded/service/gitlab-rails  
DB Adapter:     PostgreSQL  
DB Version:     11.9  
URL:            http://warhead.home.local  
HTTP Clone URL: http://warhead.home.local/some-group/some-project.git  
SSH Clone URL:  git@warhead.home.local:some-group/some-project.git  
Elasticsearch:  no  
Geo:            no  
Using LDAP:     no  
Using Omniauth: yes  
Omniauth Providers:

GitLab Shell  
Version:        13.7.0  
Repository storage paths:  
- default:      /var/opt/gitlab/git-data/repositories  
GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell  
Git:            /opt/gitlab/embedded/bin/git

Impact

From a user perspective, my account now seems to be 'bricked' from being able to create any personal projects. There are also overall business considerations as well, which will vary based on business need. For instance, is every user only allowed to have X personal projects due to server space? If so, having to arbitrarily increase the allowed project count to re-enable a user to create projects could eventually lead to resource exhaustion on the server-side.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

How To Reproduce

Please add reproducibility information to this section: