Unable to create repository as owner for a specific organisation

[eeyrjmr]

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

[lafriks]

Check that organization directory is lowercase where repositories are created

[eeyrjmr]

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

[eeyrjmr]

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

[eeyrjmr]

gitea-dump-1659720307.zip

Please try this instance

[inxonic]

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.

[inxonic]

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

gitea/models/organization/org_user.go

Lines 76 to 84 in d81e31a

	// CanCreateOrgRepo returns true if user can create repo in organization
	func CanCreateOrgRepo(orgID, uid int64) (bool, error) {
	return db.GetEngine(db.DefaultContext).
	Where(builder.Eq{"team.can_create_org_repo": true}).
	Join("INNER", "team_user", "team_user.team_id = team.id").
	And("team_user.uid = ?", uid).
	And("team_user.org_id = ?", orgID).
	Exist(new(Team))
	}

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?

[inxonic]

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

[INCO-devel]

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.

[romain-marie]

Hello, same problem for me, probably since upgrade to 1.17.0

[lunny]

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.

[lafriks]

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

[eeyrjmr]

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

[lafriks]

I know, I had to fix this for 70 organizations 😁 manually updated in database with sql

[eeyrjmr]

Eeks :( I wonder if the API can help :(
Luckily I only have 20

[lafriks]

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

[lafriks]

I will reopen this as this still can be a problem to many

[lunny]

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. :)

[reinsle]

Hi, *

have the same issue, but updating owners don't work for me.

[Sebazzz]

This also blocks transfer of repositories as this checks for "create permissions":

gitea/models/repo_transfer.go

Lines 83 to 100 in 1d8543e

	func (r *RepoTransfer) CanUserAcceptTransfer(u *user_model.User) bool {
	if err := r.LoadAttributes(); err != nil {
	log.Error("LoadAttributes: %v", err)
	return false
	}
	if !r.Recipient.IsOrganization() {
	return r.RecipientID == u.ID
	}
	allowed, err := organization.CanCreateOrgRepo(r.RecipientID, u.ID)
	if err != nil {
	log.Error("CanCreateOrgRepo: %v", err)
	return false
	}
	return allowed
	}

I temporary worked around by creating a temporary team with create permissions and adding myself to it.

[lunny]

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

[silverwind]

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.

[lafriks]

Yes, migration and doctor fix would be nice for this

[richmahn]

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;

[richmahn]

Oops, I see @silverwind already made a similar comment.

[lunny]

Or maybe we can ignore the check when it's an owner team?

[Maffsie]

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.

[xuanswe]

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!

[t0mgerman]

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!

[steadfasterX]

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")