gitea: Unable to create repository as owner for a specific organisation

Description

Post upgrading a server to 1.17.0 (from 1.16.8) the ability to create repositories for one specific organisation became forbidden for owners.

a gitea dump was performed from the windows machine and reproduced on a linux machine. More so the entire gitea instance was stripped right back to a minimal reproducible instance.

console log:

2022/08/02 22:29:00 [62e9971c] router: completed GET /IPCCA for [::1]:47414, 200 OK in 155.7ms @ user/profile.go:29(user.Profile)
2022/08/02 22:29:01 [62e9971c-2] router: completed GET /user/events for [::1]:47414, 200 OK in 1213.8ms @ events/events.go:19(events.Events)
2022/08/02 22:29:01 [62e9971d] router: completed GET /repo/create?org=22 for [::1]:47426, 403 Forbidden in 2.4ms @ repo/repo.go:132(repo.Create)

url attempting to access: http://localhost:3000/repo/create?org=2 gitea-dump-1659476345.zip

username: j password: qwertyuiop

admin: administrator password: qwertyuiop

Gitea Version

1.17.0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.35.1

Operating System

windows ( and linux)

How are you running Gitea?

windows service or from a sh

Database

MySQL

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Reactions: 1
  • Comments: 29 (21 by maintainers)

Most upvoted comments

I’m having this issue on the latest Gitea release.

I have a gitea instance with two users (an ‘admin’ user that I use rarely, and another user that I normally use) and one organisation (‘mirrors’, which I use for mirroring external repos). Since approximately August, if I create a migration under the ‘mirrors’ organisation, it fails immediately with “Forbidden”. If I create a migration under my normal account, it works, and I can then transfer the repository to the ‘mirrors’ organisation. Clicking the update button in the settings of the organisation did not help resolve this issue.

Edit: Correction, going to the organisation settings, clicking ‘teams’, clicking the title of the ‘owners’ team and then clicking update did in fact fix the issue.

I don’t think this issue is fixed… For me after upgrading from 1.16.x to 1.17.1 had still issues with lot of owner teams

1.17.1 doesn’t automatically fix orgs affected

You need to goto the “owner” team’s settings and press “update settings” (no need to change anything)

Whether there is a way todo this to all orgs (especially large instances) is a different questipn

Check that organization directory is lowercase where repositories are created

hi, just check and it is.

For clarification Site admin can create new repos for this org Org owners for this org cannot make repos Other org owners can make repos in their org Making a new team in this org with admin rights permits repos to be made

Also hit this bug, I worked around via SQL:

update team set can_create_org_repo=true where name='Owners';

Maybe we should add a migration with that? As I understand it, every “Owners” team should have this permission as it’s not configurable on the UI.

I don’t think this issue is fixed… For me after upgrading from 1.16.x to 1.17.1 had still issues with lot of owner teams

So to further isolate the problem, I did these steps:

  • confirm, it’s not possible to create a repo
  • manually set can_create_org_repo in database
  • try once more, repo can be created
  • open Settings for Owners team
  • click Update Settings without further modifications
  • check database: can_create_org_repo has been reset to false
  • try once more, repo can no longer be created

From what I see in the logs:

2022/08/15 11:00:32 [62fa2750-26] router: completed POST /repo/create for 10.15.24.69:57263, 403 Forbidden in 5.7ms @ repo/repo.go:200(repo.CreatePost)
2022/08/15 11:00:32 ...ers/web/repo/repo.go:104:checkContextUser() [I] [62fa2750-26] [SQL] SELECT * FROM "team" INNER JOIN "team_user" ON team_user.team_id = team.id WHERE team.can_create_org_repo=$1 AND (team_user.uid = $2) AND (team_user.org_id = $3) LIMIT 1 [true 6 4] - 637.148µs

This is probably the code in https://github.com/go-gitea/gitea/blob/d81e31ad7826a81fc7139f329f250594610a274b/models/organization/org_user.go#L76-L84

When executing this query manually, I get an empty result, obviously because the can_create_org_repo column is false:

# SELECT * FROM "team" INNER JOIN "team_user" ON team_user.team_id = team.id WHERE team.can_create_org_repo=true AND (team_user.uid = 6) AND (team_user.org_id = 4) LIMIT 1;
 id | org_id | lower_name | name | description | authorize | num_repos | num_members | includes_all_repositories | can_create_org_repo | id | org_id | team_id | uid
----+--------+------------+------+-------------+-----------+-----------+-------------+---------------------------+---------------------+----+--------+---------+-----
(0 rows)

# SELECT * FROM "team" INNER JOIN "team_user" ON team_user.team_id = team.id WHERE (team_user.uid = 6) AND (team_user.org_id = 4) LIMIT 1;
 id | org_id | lower_name |  name  | description | authorize | num_repos | num_members | includes_all_repositories | can_create_org_repo | id | org_id | team_id | uid
----+--------+------------+--------+-------------+-----------+-----------+-------------+---------------------------+---------------------+----+--------+---------+-----
  1 |      4 | owners     | Owners |             |         4 |       224 |          13 | t                         | f                   |  3 |      4 |       1 |   6
(1 row)

This is the case for many Owners groups, though not all:

# select count(*) from team where name='Owners' and can_create_org_repo=true;
 count
-------
    16
(1 row)

# select count(*) from team where name='Owners' and can_create_org_repo=false;
 count
-------
    24
(1 row)

Should this flag be true on the Owners groups or is this irrelevant due to some hard coded permission elsewhere for this group? If it is relevant, do we know, why it gets lost?

Once you updated 1.17.1, edit the team information then this team’s permission should be recovered.