Allow maximum permission granted to visitor/user #14074

New Issue

GiteaMirror · 2025-11-02T11:02:10-06:00

GiteaMirror commented

2025-11-02 11:02:10 -06:00

Originally created by @rozmansi on GitHub (Jan 31, 2025).

Feature Description

Hi!

I am running a Gitea server with hundreds of repositories. 99% are private.

I want to have a team (e.g. Testers) which has write access to Issues and Wiki for every repository on the server. But, I do not want to have members of this team access to the Code.
I have made a team called Testers, selected All repositories, and filled in the Allow Access to Repository Sections with appropriate level of permissions. Had to set Code unit to No Access.

This works fine for private repositories. Users, having code access via membership of other teams granted per-repository access, can access the code. Other users, members of Testers team, can only use issue tracker and Wiki.

The problem is Public repositories. Any anonymous visitor can read the code of a public repository. But the members of the Testers team cannot. They may Sign Out or use an In-private browser to access the code of a public repository. But not while being signed in.

Shouldn't Gitea use maximum granted permission when combining Public permissions with team permissions?

If some repo is public, it is annoying users need to sign out to get more access to this same repo.

Screenshots

No response

Originally created by @rozmansi on GitHub (Jan 31, 2025). ### Feature Description Hi! I am running a Gitea server with hundreds of repositories. 99% are private. I want to have a team (e.g. Testers) which has write access to Issues and Wiki for every repository on the server. But, I do not want to have members of this team access to the Code. I have made a team called Testers, selected All repositories, and filled in the Allow Access to Repository Sections with appropriate level of permissions. Had to set Code unit to No Access. This works fine for private repositories. Users, having code access via membership of other teams granted per-repository access, can access the code. Other users, members of Testers team, can only use issue tracker and Wiki. The problem is Public repositories. Any anonymous visitor can read the code of a public repository. But the members of the Testers team cannot. They may Sign Out or use an In-private browser to access the code of a public repository. But not while being signed in. Shouldn't Gitea use maximum granted permission when combining Public permissions with team permissions? If some repo is public, it is annoying users need to sign out to get more access to this same repo. ### Screenshots _No response_

GiteaMirror added the type/bug label 2025-11-02 11:02:10 -06:00

GiteaMirror closed this issue

2025-11-02 11:02:10 -06:00

GiteaMirror commented

2025-11-02 11:02:11 -06:00

@wxiaoguang commented on GitHub (Jan 31, 2025):

I think it is supported in main branch (will be 1.24 for next release)

-> Support public code/issue access for private repositories #33127 (wiki is already supported in 1.23)

And for anonymous access, there is a draft PR: WIP: Add anonymous access support for private repositories #33257

@wxiaoguang commented on GitHub (Jan 31, 2025): I think it is supported in main branch (will be 1.24 for next release) -> Support public code/issue access for private repositories #33127 (wiki is already supported in 1.23) And for anonymous access, there is a draft PR: WIP: Add anonymous access support for private repositories #33257

GiteaMirror commented

2025-11-02 11:02:11 -06:00

@wxiaoguang commented on GitHub (Feb 4, 2025):

Does it work for you?

@wxiaoguang commented on GitHub (Feb 4, 2025): Does it work for you?

GiteaMirror commented

2025-11-02 11:02:11 -06:00

@rozmansi commented on GitHub (Feb 6, 2025):

Does it work for you?

Sorry, I am running a production server, so I guess I'll wait for the 1.24 release to confirm.

@rozmansi commented on GitHub (Feb 6, 2025): > Does it work for you? Sorry, I am running a production server, so I guess I'll wait for the 1.24 release to confirm.

GiteaMirror commented

2025-11-02 11:02:12 -06:00

@wxiaoguang commented on GitHub (Feb 6, 2025):

Without really deploying an instance, does the design look good to you?

Create a private repo, and set Default access permission for all signed-in users: to Read

@wxiaoguang commented on GitHub (Feb 6, 2025): Without really deploying an instance, does the design look good to you? > Create a private repo, and set `Default access permission for all signed-in users:` to `Read`

GiteaMirror commented

2025-11-02 11:02:12 -06:00

@rozmansi commented on GitHub (Feb 10, 2025):

Without really deploying an instance, does the design look good to you?

Not quite. Suppose you have the following scenario:

Team Project X needs full control of specific repositories. User Alice is a member of this team
Team Testers, need Issues/Wiki control of all repositories. User Bob is a member of this team.
User Clara is not a member of either team. She may have some access to other repos on this server, but she is not working on Project X, nor is a tester.

Now, we have some repositories.

Private repo X, team Project X has full access to it.
Private repo Y.
Public repo P.

Now, focus on user Bob.
He can use the Issues/Wiki of all projects. Correct.
He cannot see the Code of private repos X and Y. Correct. He is not a developer.
Since repo P is public, user Bob should have at least that many permissions anonymous visitors have. But since he is a member of the group Testers, he is denied Code access to all repos: including the public ones. So, Bob needs to sign-out of Gitea to gain enough permissions to read code in the public repository P.

Create a private repo, and set Default access permission for all signed-in users: to Read

This means I give all signed-in users permission to use Issues/Wiki. Including Clara, who is not a member of any team with access to this private repository, neither a member of Testers group.

In other words your proposal grants too much permission to private repositories.

To make matters worse, I am using LDAP authentication and have quite a lot of users that can log in to Gitea. They are developers of some repos, but not others. Some users are testers only. So, I would not be comfortable to select Default access permission for all signed-in users: to Read and allow developers access to foreign private repositories.

Maybe the solution to my proposal could be simply implemented just by changing the ACL checks from

if mayAccess(repo, user, unit, forReading) {
    read_stuff();
}

to

if mayAccess(repo, user, unit, forReading) || (isPublic(repo) && mayAccessAnonymously(repo, unit, forReading)) {
    read_stuff();
}

The catch is the || fallback for public repos.

@rozmansi commented on GitHub (Feb 10, 2025): > Without really deploying an instance, does the design look good to you? Not quite. Suppose you have the following scenario: 1. Team Project X needs full control of _specific_ repositories. User Alice is a member of this team 2. Team Testers, need Issues/Wiki control of _all_ repositories. User Bob is a member of this team. 3. User Clara is not a member of either team. She may have some access to other repos on this server, but she is not working on Project X, nor is a tester. Now, we have some repositories. - Private repo X, team Project X has full access to it. - Private repo Y. - Public repo P. Now, focus on user Bob. He can use the Issues/Wiki of all projects. Correct. He cannot see the Code of private repos X and Y. Correct. He is not a developer. Since repo P is public, user Bob should have at least that many permissions anonymous visitors have. But since he is a member of the group Testers, he is denied Code access to all repos: including the public ones. So, Bob needs to sign-out of Gitea to gain enough permissions to read code in the public repository P. > > Create a private repo, and set `Default access permission for all signed-in users:` to `Read` This means I give all signed-in users permission to use Issues/Wiki. Including Clara, who is not a member of any team with access to this private repository, neither a member of Testers group. In other words your proposal grants too much permission to private repositories. To make matters worse, I am using LDAP authentication and have quite a lot of users that can log in to Gitea. They are developers of some repos, but not others. Some users are testers only. So, I would not be comfortable to select `Default access permission for all signed-in users:` to `Read` and allow developers access to foreign private repositories. Maybe the solution to my proposal could be simply implemented just by changing the ACL checks from ```Go if mayAccess(repo, user, unit, forReading) { read_stuff(); } ``` to ```Go if mayAccess(repo, user, unit, forReading) || (isPublic(repo) && mayAccessAnonymously(repo, unit, forReading)) { read_stuff(); } ``` The catch is the `||` fallback for public repos.

GiteaMirror commented

2025-11-02 11:02:12 -06:00

@wxiaoguang commented on GitHub (Jun 24, 2025):

Hmm, I think it is a bug.

Let's fix it in Fix querying teams by permission #34827

@wxiaoguang commented on GitHub (Jun 24, 2025): Hmm, I think it is a bug. Let's fix it in Fix querying teams by permission #34827

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#14074