Fix restricted visibility API level permissions

Related to #550131

What does this MR do and why?

What?

• Admin-mode allows an admin to use GitLab as a regular user. To access tasks and endpoints that require admin privileges, the admin in admin-mode would have to re-authenticate each time.
• The security bug is specifically around admins in admin-mode being able to bypass restricted visibility levels via API without the required admin_mode PAT scope.
  • Currently, when the admin-mode application setting is true, any admin who creates a PAT with an api scope can bypass the restricted visibility levels.
  • Instead, an admin should need a PAT with both an api & admin_mode scope to bypass the restricted visibility levels

Scenario example (Current behaviour on Gitlab):

• Regular admin -> restricts visibility to public -> admin can still create public groups, projects & snippets
• Admin, admin_mode: true (emulate regular user), PAT scope(s): api -> restricts visibility to public -> admin can create public groups, projects & snippets
• Admin, admin_mode: true (emulate regular user), PAT scope(s): api, admin_mode -> restricts visibility to public -> admin can create public groups, projects & snippets

Scenario example (On this MR's branch):

• Regular admin -> restricts visibility to public -> admin can still create public groups, projects & snippets
• Admin, admin_mode: true (emulate regular user), PAT scope(s): api -> restricts visibility to public -> admin cannot create public groups, projects & snippets
• Admin, admin_mode: true (emulate regular user), PAT scope(s): api, admin_mode -> restricts visibility to public -> admin can create public groups, projects & snippets

Why?

This MR ensures that API requests by self-managed admins follow the same rules as the web UI by forcing them to use a PAT with both api and admin_mode scopes to create projects/groups/snippets, when restricted visibility levels are chosen.

How to set up and validate locally

For visuals, see the main issue

• Turn on admin_mode via the API, UI, or rails console
• As an admin, go to the admin area > settings > general > Visibility and access controls
• Under Restricted visibility levels , select the public option & click on save
  • NB: The Default group/project/snippet visibility & Restricted visibility levels both should be different (ideally: 3 Private & 1 Public)
• Before cloning the branch, verify the current behaviour on your GDK
  • As an admin, create a pat1 with an api scope and pat2 with an api & admin_mode scope
  • Run the following curl requests with pat1 and pat2 to confirm the same behaviour (both should create groups, projects & snippets)

Curl Requests

/groups

curl --request POST "https://gdk.test:3443/api/v4/groups" \
  --header "PRIVATE-TOKEN: <pat1 or pat2>" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "pat1 or pat2",
    "path": "pat1 or pat2",
    "visibility": "public"
  }'

/projects

curl --request POST "https://gdk.test:3443/api/v4/projects" \
  --header "PRIVATE-TOKEN: <pat1 or pat2>" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "pat1 or pat2",
    "path": "pat1 or pat2",
    "visibility": "public"
  }'

/snippets

Create a json

cat > snippet.json <<'EOF'
{
  "title": "This is a snippet",
  "description": "Hello World snippet",
  "visibility": "internal",
  "files": [
    {
      "content": "Hello world",
      "file_path": "test.txt"
    }
  ]
}
EOF

curl --request POST "https://gdk.test:3443/api/v4/snippets" \
  --header "PRIVATE-TOKEN: <pat1 or pat2>" \
  --header "Content-Type: application/json" \
  --data @snippet.json

• To verify the fix, clone the branch & repeat the curl requests
  • Run the curls requests with pat1 and pat2 to confirm that:
    • pat1 is not allowed to create public or your restricted groups, projects & snippets
    • pat2 (with admin_mode scope) is allowed to create public or your restricted groups, projects & snippets

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.