Skip to content

Restricting imports to users with Maintainer and above roles

Problem

As reported in A user with developer role (group) can import p... (#358750 - closed), a user with only developer privileges can't create protected branches. However, a developer can import projects that contain malicious external gitlab-ci.yml files that already are inside protected branches. If a Maintainer doesn't inspect external include(s) and makes any changes to protected branch, the automatic pipeline run will send sensitive data to malicious developer.

A solution to that would be to restrict importing projects to users with Maintainer and above role.

In case of GitLab groups and projects migration, also migrating groups would need to be restricted, as they (might) contain projects.

Restricting imports to users with Maintainer Role is a breaking change as we are Changing the definition of an existing API.

There was a concern raised that "Updating all project imports to be maintainer and above creates a behavioural breaking change for existing users. The syntax of initiating a project remains the same (if API is used) but a lot of users will no longer be able to import their projects."

Following the suggestion we implemented a metric to gather the data on what kind of a role a user has when initiating an import.

We now have some data telling us users in which roles are importing projects. In summary, in December 2022 there were almost 14K projects imported, 3K out of ~14K were not done by the Maintainer or Owner. Out of 3K, 1466 were done with BitBucket importer by Not a Member, which means that users that are not members of a group can import BitBucket projects to this group. This is potentially another problem, as users that are not members of a group should not be able to import anything to that group. GitHub projects migrated by Not a member is 409, Bulk import group Not a member is 4.

Out of 14K there’s only 50 projects migrated by Developer or Reporter (1 project). This data supports the proposal of going for a breaking change.

Proposed solution

We should restrict importing projects to maintainer and above or no one - aligned with project_creation_level.

In case of GitLab groups and projects migration, also migrating groups needs to be restricted, as they (might) contain projects.

This is a breaking change for the API, and hence can only be done in 16.0

From comment:

  • Don't display groups/namespaces where the user is not maintainer or above as possible destinations
  • In the list view, communicate a user can only import to places where they are maintainer or above. Potentially an additional sentence in the description or a popover/tooltip on the 'To GitLab'/'To new group' table header
  • Update to the docs to reflect this requirement

Implementation details

Check project_creation_level and if:

  • DEVELOPER and above - import_creation_level should be Maintainer and above
  • MAINTAINER and above - import_creation_level should be Maintainer and above
  • NO ONE - import_creation_level should be no one
Edited by Magdalena Frankiewicz