Skip to content

Permission hierarchy and content ownership inconsistencies

Summary

GitLab has inconsistent policies around content ownership and permission inheritance that create both security vulnerabilities and usability problems. The system lacks coherent rules for when creators should receive ownership permissions versus when they should inherit existing roles.

Problem Areas

1. Inconsistent Creator Ownership Between Object Types

  • Subgroups: Creators automatically become Owners (complained about in security context, see below)
  • Projects: Creators do not automatically become Owners (#17095)

This inconsistency creates confusion and competing demands from different user groups.

2. Competing Valid Requirements

Security Perspective:

  • Maintainers creating subgroups shouldn't automatically gain Owner privileges
  • This allows unauthorized access to group management functions
  • Enables potential external user invitation and infrastructure changes
  • Violates principle of least privilege

Usability Perspective:

  • Creators should own their content to manage it independently
  • Without ownership, creators can't delete/move their own projects
  • Forces administrative burden on group Owners for routine cleanup
  • Matches user expectations from other platforms (Google Drive, etc.)

3. Instance-Level Policy Bypass

Group Owners can set less restrictive project creation permissions than instance administrators intended, undermining security policies.

Root Cause Analysis

The system lacks contextual permission policies that can distinguish between:

  • Content creation (should grant ownership for management)
  • Infrastructure creation (should respect organizational hierarchy)
  • Administrative boundaries (instance policies should be enforceable)

Proposed Solution

1. Contextual Ownership Model

Implement different ownership rules based on object type and organizational context:

Projects (Content):

  • Creators become Owners by default
  • Enables independent content management
  • Supports individual productivity workflows

Subgroups (Infrastructure):

  • Creators inherit their parent group role by default
  • Prevents unintended privilege escalation
  • Maintains organizational security boundaries

Administrative Override:

  • Group Owners can configure creator ownership policies
  • Instance Admins (in the future: Organization Owners) can enforce stricter inheritance rules
  • Explicit settings for different object types

2. Hierarchical Policy Enforcement

  • Instance-level settings provide security floor that cannot be bypassed
  • Group-level settings can be more restrictive but not less restrictive
  • Clear precedence rules with administrative override capabilities

3. Graduated Ownership Options

Instead of binary Owner/Non-Owner, consider:

  • Content Owner: Can delete/move own content, limited administrative access
  • Infrastructure Owner: Full administrative privileges
  • Inherited Role: Maintains original permissions

Implementation Considerations

Security Safeguards

  • Audit logging for all ownership grants and escalations
  • Separation of content management from administrative privileges

Migration Strategy

  • Granular rollout with per-group configuration
  • Backward compatibility during transition period
  • Clear communication about behaviour changes

User Experience

  • Consistent behaviour within object types
  • Clear indication of permission sources (inherited vs. granted)
  • Predictable outcomes for content creators
Subgroup privilege escalation

When a maintainer in our main group, creates a sub-group (or sub-sub-group) he's given owner privileges on the sub-group, overriding his inheritance.

Steps to reproduce

  • Create a group
  • Allow maintainers to create sub-groups
  • Add a second member as maintainer
  • With the second user, create a sub-group
  • You are an owner within that sub-group, despite your inherited privileges

Example Project

The sub-groups where this happened no longer have this issue since we had to fix it urgently. I rather not share our groups publicly either.

What is the current bug behavior?

When a maintainer in our main group, creates a sub-group (or sub-sub-group) he's given owner privileges on the sub-group, overriding his inheritance. This means that within the subgroup he's able to do anything an owner can, (ie. Manage group members) which is not something we want.

We can not allow people from outside our organization to have access to our repositories (having more than one owner exposes the risk of inviting people outside of the group by mistake), nor we want people changing group settings or adding CI runners to groups / projects without explicit authorization.

We also can't have a single owner creating sub-groups for every one in our organization, so we need the maintainers to be able to create sub-groups, but their privileges should NOT be changed to Owner. NEVER.

What is the expected correct behavior?

The user should inherit the group privileges when creating a sub-group.

Privileges are there to allow people to do stuff, but also to prevent them from doing some other stuff. It's not cool to give a user more privileges than the ones he inherited, unless it's done manually.

Output of checks

This bug happens on GitLab.com

Possible fixes

The user should inherit its privileges when creating a sub-group, don't "automagically" give Owner privileges to ANYONE that's not an owner on a parent group.

Edited by Christina Lohr