Gitea: Error while displaying public repo (404)

[DblK]

I saw something that could be a bug (maybe Units).
If you following the procedure you will see a 404 error:
1) Create an organization with user1 (user1 is in owner team)
2) Create public repo with user1
3) Add user2 to organization but do not put him in a team
4) Access with user2 to the organization page
5) click on the repository
6) 404 error

You can also have a 404, by accessing a public repository in organization with a user not part of it.

It seems that the 404 error is triggered by routers/repo/view.go#L270.

commit: 977dcf96e0d9c5dded47ac6066fad8979a9f74f9

[lunny]

So what's permission should a member of an organization who are not in any team have?

[pgaskin]

I had this bug too after I updated my server yesterday.

[DblK]

@lunny, depend on the type of the repo:

• If it's private none but should lead to 403 in my opinion instead of 404. (but actually I think they are not displayed)
• If it's public, all access like he is not part of the organization at all

And obviously, permit a user outside of an organization to view public repository even if not part of it.

Another way to have 404, seems #1797

[lunny]

@DblK, in fact, we need a document to describe all the permission settings we like Gitea do.

[camlafit]

Hi

In my case if an user is only organization collaborators and in any orgnization team , i can't see any organization repo.
To get repo list , it's possible only if set in organization owner team.

But in this case this user get a 404 on repo page. In log I show :

[...routers/repo/view.go:270 Home()] [E] Home: Cannot find any unit on this repository which you are allowed to acces

It's possible I've followed #1797 before (convert a personal repo to organization repo)

[lunny]

Which version did you use? I think https://github.com/go-gitea/gitea/commit/b0308d86dc124f17d6b67e9d1022a4085c9267e1 has fixed that.

[camlafit]

I've just tried with master, 5min ago

On 1.1.1 it's ok

[lunny]

So a public repo of an organization should be visited by anyone? So that the units of team should be only applied for private repos of organization?

[camlafit]

If an user is set as collaborator or as member to any team (owner or not), he should be show repositories.
If a organization is public, their repositories should be public also

[lunny]

Please confirm #1812 fix this issue.

[lunny]

I think #1812 resolved this and please feel free to reopen it.

[camlafit]

Hi

sorry :/
Can you reopen, just tried with master. 404 is again present.

2017/06/20 10:36:54 [I] Log Mode: File(Info)
2017/06/20 10:36:54 [I] XORM Log Mode: File(Info)
2017/06/20 10:36:54 [I] Cache Service Enabled
2017/06/20 10:36:54 [I] Session Service Enabled
2017/06/20 10:36:54 [I] Migration: add user openid table
2017/06/20 10:36:56 [I] Migration: change the key_id and primary_key_id type
2017/06/20 10:36:58 [I] Migration: add show field in user openid table
2017/06/20 10:36:59 [I] Migration: generate and migrate repo and wiki Git hooks
2017/06/20 10:37:00 [I] Migration: change mirror interval from hours to time.Duration
2017/06/20 10:37:01 [I] Migration: add field for repo size
2017/06/20 10:37:01 [I] This migration could take up to minutes, please be patient.
2017/06/20 10:37:21 [I] Migration: add commit status table
2017/06/20 10:37:22 [I] Migration: add primary key to external login user
2017/06/20 10:37:24 [I] Migration: add field for login source synchronization
2017/06/20 10:37:25 [I] Migration: add units for team
2017/06/20 10:37:26 [I] Migration: remove columns from action
2017/06/20 10:38:19 [I] Migration: give all units to owner teams
2017/06/20 10:38:30 [I] Git Version: 2.1.4
2017/06/20 10:38:31 [I] Run Mode: Production
2017/06/20 10:38:31 [I] Listen: http://0.0.0.0:3001

Use is admin and owner organization, it can't access or change settings on repository. 404 display
I can provide an access to this server.

[lunny]

Please give more details.

[camlafit]

Hi

On my log server I get this :

2017/06/20 10:38:31 [I] Listen: http://0.0.0.0:3001
2017/06/20 11:35:12 [...routers/repo/view.go:274 Home()] [E] Home: Cannot find any unit on this repository which you are allowed to access
2017/06/20 11:35:22 [...routers/repo/view.go:274 Home()] [E] Home: Cannot find any unit on this repository which you are allowed to access
2017/06/20 11:35:37 [...routers/repo/view.go:274 Home()] [E] Home: Cannot find any unit on this repository which you are allowed to access
2017/06/20 11:36:15 [...routers/repo/view.go:274 Home()] [E] Home: Cannot find any unit on this repository which you are allowed to access
2017/06/20 11:36:39 [...routers/repo/view.go:274 Home()] [E] Home: Cannot find any unit on this repository which you are allowed to access
2017/06/20 11:36:43 [...ules/context/repo.go:529 func1()] [E] CheckUnit: You are not allowed to visit this repository unit: 7
[...]

As I don't what kind of information could be useful, I can provide an access to this server.

[lunny]

@camlafit could you tell me the example?

[camlafit]

Hi

On 1.1.1 , I've an organization with some repositories. Two account an admin (created on installation) and an normal user set as owner on the organization.

admin and user can check all repositories .

If I update to master, these accounts can always view organization and theirs repositories. But to one repositories, show it return a 404 (to each account)
And setting repository is also a 404.

I presume difference between this repository and the others, is the creation step. Normaly from admin account I create repository set directly on the organization. For this repo, I think to have create first on user workspace and move to organization after.

On log I get this error : cannot find any unit.

[pgaskin]

It seems to be a migration issue with the newer finer repository permission settings.

[lunny]

@camlafit Is this repo a private or a public? Is this repo on one organization?

[camlafit]

It's in an organization and it's private
Other repo is this organization are also private

[lunny]

Then if all the people is on a team? and is this team have read or write permission to the repo?

[camlafit]

the two accounts are set in team owner , first is an admin account, other standard.
an other account is set only as collaborator with write right and not set in owner team

In this 3 cases, they get a 404 after update

[lunny]

@camlafit maybe #1873 and #1968 fix this? which version did you test recently?

[camlafit]

I've tried master version two day ago : 5db8cf3bd1505c5c829de2a928d35ea19808b6c2 then these commits should be present.

[lunny]

@DblK please confirm your issue.
@camlafit have your instance migrated from Gogs?

[camlafit]

It's a from scratch gitea installation, gitosis import with api.

[lafriks]

@lunny maybe when creating repository from API units are not correctly created?

[camlafit]

In this specific case, repo and orgo was created only with gitea interface.

[lunny]

@lafriks Yes. maybe you are right! I will check that.

[olymk2]

Just hit this myself, anyone find a work around ?

I cant change the settings of the repo as admin because the page just 404s and i get the error below in the logs.

Home: Cannot find any unit on this repository which you are allowed to access

[camlafit]

Hi

Actual better solution (in my case) revert in 1.1.1 version. I don't try
with 1.1.2
​
At least allow admin account to go settings page to any repo/organization
should be interessting. So should be possible to correct manualy

[lunny]

I have tested many times but didn't reproduce the issue. @camlafit could you show me some tables data on your database so that I can investigate the reason. On team table there is a column named unit_types. If it's empty, you will get 404 on repository page.

[camlafit]

Hi

select * from team;
| id | org_id | lower_name | name   | description | authorize | num_repos
| num_members | unit_types          |
|  1 |      2 | owners     | Owners |             |         4 |         7
|           3 | [1,2,3,4,5,6,7,8,9] |

It's same list on unit_types to all row.

[lunny]

@camlafit OK. The table is normal. Then could you find the repo_unit table and execute SELECT * FROM repo_unit WHERE repo_id =? the ? should be the 404 repository's id.

[camlafit]

It's empty.

SELECT * FROM repo_unit WHERE repo_id=25;
Empty set (0.00 sec)

[lafriks]

@camlafit are there any records in rep_unit table?

[camlafit]

With repo without problem I get data.

MariaDB [gitea-webelys]> SELECT * FROM repo_unit WHERE repo_id=16;

+----+---------+------+-------+--------+--------------+
| id | repo_id | type | index | config | created_unix |
+----+---------+------+-------+--------+--------------+
| 69 |      16 |    1 |     1 | {}     |   1490025629 |
| 70 |      16 |    2 |     2 | {}     |   1490025630 |
| 71 |      16 |    3 |     3 | {}     |   1490025630 |
| 72 |      16 |    4 |     4 | {}     |   1490025630 |
| 73 |      16 |    5 |     5 | {}     |   1490025630 |
| 74 |      16 |    6 |     6 | {}     |   1490025630 |
| 75 |      16 |    7 |     7 | {}     |   1490025630 |
+----+---------+------+-------+--------+--------------+
7 rows in set (0.00 sec)

[lafriks]

than it looks like it is migration issue and unit types must be added to that repository

[camlafit]

How ?

But if I understand your queries, if we have data in team.unit_types we must get also data in repo_unit ? Is not possible to check it and update database ?

At least a generic SQL workaround could be useful :)

[lunny]

@lafriks @camlafit we could do two work, first is fix the bug, and second is add an reset button on admin panel to reset all repo's units. I will send a PR to do them.

[olymk2]

exactly the same for missing missing entries in the unit_types tables, is there a way to regenerate the correct entries ?

[lafriks]

@lunny why reset all repo units? That would be very dangerous as it would lose repository settings on disabled (wiki/issues) etc

[camlafit]

Hi

A reset GUI looks interestting :) In this case could be accessible repo by
repo from admin/repos page. Repo settings page could be not accessible if
units are missing.
This option could be useful in this case but also if user or admin miss its
configuration and lost access.

[rhaamo]

Hi,

I've got the same issue (table repo_unit empty) from a migration from gogs.

I "manually" created the missing entries in the table with inserts like, for each repository.id :

insert into repo_unit (`repo_id`, `type`, `index`, `config`) values (73, 1, 1, '{}');

With 1,1 replaced by 1,1 to 7,7.

Should that be sufficient ?

[lunny]

Yes, it's enough for working. @rhaamo

[camlafit]

Hi

I've done on my server and looks ok. On 28 repo, were 6 without unit values.

[olymk2]

@rhaamo cheers, based on that i made a quicker version for anyone that wants it in the future.

tested on sqlite db only

# get repository's ids missing unit types
select repository.id from repository left join repo_unit
on repository.id=repo_id where repo_id is null ;

# create records so you can accually edit and access them again
insert into repo_unit (`repo_id`, `type`, `index`, `config`) 
select repository.id, types.*, '{}' from repository
left join repo_unit on repository.id=repo_id 
left join (
  select 1,1
  UNION ALL select 2,2
  UNION ALL select 3,3
  UNION ALL select 4,4
  UNION ALL select 5,5
  UNION ALL select 6,6
  UNION ALL select 7,7) as types
where repo_id is null; 

this kicked all my repo's back into action o/

[silverwind]

I also got hit by this after updating a instance. The query in https://github.com/go-gitea/gitea/issues/1794#issuecomment-316824479 didn't work on MySQL, so I ran queries suggested in https://github.com/go-gitea/gitea/issues/1794#issuecomment-316613399, which fixed it.

[lunny]

I think that's because you lost migration v16 https://github.com/go-gitea/gitea/blob/master/models/migrations/v16.go#L47.

[silverwind]

I was upgrading from 1.1.0+135-gfcc7cda to 1.1.0+474-gbe29d5f7, if that's of any help. The affected repos were definitely working before.

[jhasse]

@lafriks showed my on Discord how to fix this for MySQL (thanks again!):

insert into repo_unit (`repo_id`, `type`, `index`, `config`) 
select repository.id, types.*, '{}' from repository
left join repo_unit on repository.id=repo_id 
left join (
  select 1 as col1, 1 as col2
  UNION ALL select 2,2
  UNION ALL select 3,3
  UNION ALL select 4,4
  UNION ALL select 5,5) as types on (1=1)
where repo_id is null;

[lafriks]

For 1.3.0 this SQL helps:

insert into repo_unit ("repo_id", "type", "config") select repository.id, types.*, '{}' from repository left join repo_unit on repository.id=repo_id left join ( select 1 UNION ALL select 2 UNION ALL select 3 UNION ALL select 4 UNION ALL select 5) as types on (1=1) where repo_id is null;

But could be useful if someone could pinpoint what these repos have different than others to understand why migration for them fail

[lunny]

Found this will happen when upgrade 1.1.3 to 1.2.x if he ever upgraded from Gogs. Maybe add this as an know issues and resolve solutions on docs.

[lunny]

I will close this now and feel free to reopen it.