gitea
gitea copied to clipboard
go-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
Check that organization directory is lowercase where repositories are created
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
Correction: the minimal reproducible example works. As the instance was being stripped back I kept trying to see at what point it "worked". The browser cache gave the false sense of "not working" while I was stripping back.
This means some interaction cleared this fault but relying on "deleting" isn't a good way... I will start stripping back again to create a real demonstrable instance
Also seeing this issue in our env after upgrading to 1.17.0 from 1.15.10, running with container and PostgreSQL.
I could verify all of eeyrjmr's observations:
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
Plus I'm quite sure I could create an org repo as an owner after the upgrade in one case, which is now no longer working. So there might still be other circumstances that have impact on this.
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?
So to further isolate the problem, I did these steps:
- confirm, it's not possible to create a repo
- manually set
can_create_org_repoin database - try once more, repo can be created
- open Settings for Owners team
- click Update Settings without further modifications
- check database:
can_create_org_repohas been reset tofalse - try once more, repo can no longer be created
We also have at least one org for which members of the 'owners' team seemingly can't create new repositories. Our instance is also running 1.17.0, having been upgraded from the previous versions.
OK. The bug is when updating owners team, the incorrect update to can_create_org_repo false. I will send a PR to fix that.
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
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
I know, I had to fix this for 70 organizations 😁 manually updated in database with sql
Ideally this should be fixed by migration but we are too late for that in 1.17 release, probably migration for 1.18 + doctor command to fix this
I know, I had to fix this for 70 organizations 😁 manually updated in database with sql
You don't need to update them once, you can update one when you find it wrong. :)
This also blocks transfer of repositories as this checks for "create permissions":
https://github.com/go-gitea/gitea/blob/1d8543e7db58d7c4973758e47f005c4d8bd7d7a3/models/repo_transfer.go#L83-L100
I temporary worked around by creating a temporary team with create permissions and adding myself to it.
Once you updated 1.17.1, edit the team information then this team's permission should be recovered.
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.
We had a 103 orgs not able to create repos, so a bit of an inconvenience. I had to do this in mysql to fix at least for owners:
update team set can_create_org_repo = 1 where lower_name = "owners" and can_create_org_repo = 0;
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.
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.
This trick works for me. Thanks!
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.
Recently did an update that jumped from quite an old version up past 1.17 - and this was what worked for us. Thanks @Maffsie!
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.
finally ! thanks for that one. It works that way now! using gitea 1.19.4 (Org -> tab "Teams" -> click "owners" team title -> Settings -> click "Update Settings")
