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.