-
-
Notifications
You must be signed in to change notification settings - Fork 6k
Closed
Description
- Gitea version (or commit ref): 1.15.2 built with GNU Make 4.1, go1.16.7 : bindata, sqlite, sqlite_unlock_notify
- Git version: 2.33.0.2
- Operating system: Windows Server 2012 R2
Running using your pre-built Win x64 binary. This is being started/stopped using a Windows service created per your installation instructions running as a local user with 'full control' of relevant folders. - Database (use
[x]
):- PostgreSQLMySQLMSSQLSQLiteTo pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
- Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)No (Couldn't register or email was taking a super long time to come. May have to try this later.)To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Description
- Create new organization.
- Create two new empty repos.
- Add a new restricted user.
- Create new team in the new organization with specific repo access, read, with everything toggled OFF except code.
- Add the new user to this team.
- Add the team to only ONE of the two repos with read access.
Now log in with the new user and note that ALL repos in the organization show up, however when trying to access the repo that the team is NOT on you get a 404. I don't know if this is by design but IMO the other repos should not even show up at all when specific repo access has been set on that team, ONLY the repos that team is a part of should be listed. This is related to #17003.
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
zeripath commentedon Sep 14, 2021
We need logs.
SoulSeekkor commentedon Sep 14, 2021
I'll have to change the verbosity and add some tomorrow morning, the warning level didn't generate any.
SoulSeekkor commentedon Sep 15, 2021
So I set it to trace to finally get one in the gitea.log, here is the relevant entry from that file:
2021/09/15 14:17:36 ...ices/auth/session.go:57:SessionUser() [T] Session Authorization: Found user[9]
2021/09/15 14:17:36 ...ices/auth/session.go:73:SessionUser() [T] Session Authorization: Logged in user 9:testuser
2021/09/15 14:17:36 models/repo.go:349:getUnits() [T] repo.Units: [0xc0072a54d0 0xc0072a5530 0xc0072a5590]
2021/09/15 14:17:36 ...s/repo_permission.go:154:func1() [T] Permission Loaded for 9:testuser in 8:Scripts/sqlserver:
Permissions: AccessMode: 0:none, 0 Units, 0 UnitsMode(s): [ ]
2021/09/15 14:17:36 ...s/context/context.go:185:HTML() [D] Template: status/404
Here is the entry from the access.log:
x.x.x.x:60460 - testuser [15/Sep/2021:14:17:36 -0500] "GET /Scripts/sqlserver HTTP/2.0" 404 18396 "" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36 Edg/93.0.961.47"
SoulSeekkor commentedon Sep 20, 2021
Verified similar to #17003 that this appears to work differently with a regular vs restricted user. In this case BOTH repos still incorrectly show up (as the repo without the team added to it is still visible) but at least when the user goes to it they don't receive a 404...instead it shows the same "This repository does not contain any content." message as the repo they DO have access to.
SoulSeekkor commentedon Sep 20, 2021
After testing further, an even bigger issue is that after committing something to the second repo (of which the team is NOT a part of) the regular test user has access to that repo and is able to see files/content in that repo when they should not be able to...
SoulSeekkor commentedon Sep 20, 2021
Also even though the team is set to code only ALL of the tabs show up for that repo they should not have access to including issues (of which it was able to create a new issue), pull requests, wiki, etc.
zeripath commentedon Oct 27, 2021
I think I've figured out what the problem is here and I think this should be fixed by the associated PR.