Administrator-only permission to delete a repository and prohibit forks for everyone #8710

New Issue

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

GiteaMirror commented

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

Originally created by @KarenArzumanyan on GitHub (Mar 16, 2022).

My goal:

Set up systems in the local network for the organization with differentiation of user rights:
Read - view content only. (have, use)
Write - permissions to write to the repository create branches and pull requests. (have, use)
Administrator - access control and full rights to the repository. (have, but not used in my case)
Prohibit users from creating their own repositories and forking others. Work should only be done on existing repositories. They can only be created and managed by the system administrator.

Problems:

A user with write access has access to the "Danger Zone" section, this is very dangerous, he can delete the repository, wiki and other important data.
A user with any rights can fork the repository. Moreover, he becomes an administrator in the fork and can then transfer rights to a third user who did not have access to the original repository.

Solution:

Please change the access rights to the "Danger Zone" section, only for the repository administrator. A user with write access should not have access to it.
Please add a global option to the configuration file to prohibit the creation of forks. Here, for a similar request, they suggested changing the theme/template, but this is not a solution because it remains possible to create a fork through the link https://git-server/repo/fork/{id}, which creates a security hole. The MAX_CREATION_LIMIT=0 option does not disable forks.
In addition to the prohibition of forks, please add an option to prohibit users from creating repositories on their own. Now I did it through MAX_CREATION_LIMIT=0, but this is not very convenient because the button is still available in the interface, although a message is displayed that the limit is 0.

If there is already a solution, please let me know.

Originally created by @KarenArzumanyan on GitHub (Mar 16, 2022). My goal: 1) Set up systems in the local network for the organization with differentiation of user rights: Read - view content only. (have, use) Write - permissions to write to the repository create branches and pull requests. (have, use) Administrator - access control and full rights to the repository. (have, but not used in my case) 2) Prohibit users from creating their own repositories and forking others. Work should only be done on existing repositories. They can only be created and managed by the system administrator. Problems: 1) A user with write access has access to the "Danger Zone" section, this is very dangerous, he can delete the repository, wiki and other important data. 2) A user with any rights can fork the repository. Moreover, he becomes an administrator in the fork and can then transfer rights to a third user who did not have access to the original repository. Solution: 1) Please change the access rights to the "Danger Zone" section, only for the repository administrator. A user with write access should not have access to it. 2) Please add a global option to the configuration file to prohibit the creation of forks. Here, for a similar request, they suggested changing the theme/template, but this is not a solution because it remains possible to create a fork through the link https://git-server/repo/fork/{id}, which creates a security hole. The MAX_CREATION_LIMIT=0 option does not disable forks. 3) In addition to the prohibition of forks, please add an option to prohibit users from creating repositories on their own. Now I did it through MAX_CREATION_LIMIT=0, but this is not very convenient because the button is still available in the interface, although a message is displayed that the limit is 0. If there is already a solution, please let me know.

GiteaMirror added the type/proposal label 2025-11-02 08:15:12 -06:00

GiteaMirror commented

2025-11-02 08:15:13 -06:00

@KarenArzumanyan commented on GitHub (Apr 1, 2022):

The described security holes are very critical, at least for me.
Could you look at the implementation, the solution seems to be simple.
Thank you in advance.

@KarenArzumanyan commented on GitHub (Apr 1, 2022): The described security holes are very critical, at least for me. Could you look at the implementation, the solution seems to be simple. Thank you in advance.

GiteaMirror commented

2025-11-02 08:15:13 -06:00

@KarenArzumanyan commented on GitHub (Apr 1, 2022):

There is still a problem. When commenting on the code, an email is sent with a notification and part of the source code.
Is there a way to turn off sending parts of the code?
Or add such an option, or is there already such a setting?

@KarenArzumanyan commented on GitHub (Apr 1, 2022): There is still a problem. When commenting on the code, an email is sent with a notification and part of the source code. Is there a way to turn off sending parts of the code? Or add such an option, or is there already such a setting?

GiteaMirror commented

2025-11-02 08:15:13 -06:00

@lunny commented on GitHub (Apr 2, 2022):

The described security holes are very critical, at least for me. Could you look at the implementation, the solution seems to be simple. Thank you in advance.

I cannot reproduce it. Please send email to security at gitea.io if you can confirm that.

@lunny commented on GitHub (Apr 2, 2022): > The described security holes are very critical, at least for me. Could you look at the implementation, the solution seems to be simple. Thank you in advance. I cannot reproduce it. Please send email to security at gitea.io if you can confirm that.

GiteaMirror commented

2025-11-02 08:15:13 -06:00

@KarenArzumanyan commented on GitHub (Apr 2, 2022):

The described security holes it problems:

A user with write access has access to the "Danger Zone" section, this is very dangerous, he can delete the repository, wiki and other important data.

A user with any rights can fork the repository. Moreover, he becomes an administrator in the fork and can then transfer rights to a third user who did not have access to the original repository.

and can then transfer rights to a third user who did not have access to the original repository

@KarenArzumanyan commented on GitHub (Apr 2, 2022): The described security holes it problems: > 1) A user with write access has access to the "Danger Zone" section, this is very dangerous, he can delete the repository, wiki and other important data. > 2) A user with any rights can fork the repository. Moreover, he becomes an administrator in the fork **_and can then transfer rights to a third user who did not have access to the original repository_**. **_and can then transfer rights to a third user who did not have access to the original repository_**

GiteaMirror commented

2025-11-02 08:15:13 -06:00

@mohe2015 commented on GitHub (Apr 3, 2022):

I personally don't see the point in the second one as you could also just give somebody the code if you have access to it.

@mohe2015 commented on GitHub (Apr 3, 2022): I personally don't see the point in the second one as you could also just give somebody the code if you have access to it.

GiteaMirror commented

2025-11-02 08:15:14 -06:00

@KarenArzumanyan commented on GitHub (Apr 3, 2022):

I personally don't see the point in the second one as you could also just give somebody the code if you have access to it.

See my goals at the beginning.
Git is used in an organization, not open source.
The organization has strict rules for working with the code, there are access restrictions, it is forbidden to transfer the code.
All actions must be logged and monitored by the security service.

@KarenArzumanyan commented on GitHub (Apr 3, 2022): > I personally don't see the point in the second one as you could also just give somebody the code if you have access to it. See my goals at the beginning. Git is used in an organization, not open source. The organization has strict rules for working with the code, there are access restrictions, it is forbidden to transfer the code. All actions must be logged and monitored by the security service.

GiteaMirror commented

2025-11-02 08:15:14 -06:00

@zeripath commented on GitHub (Apr 19, 2022):

A user with write access has access to the "Danger Zone" section, this is very dangerous, he can delete the repository, wiki and other important data.

As @lunny writes above I cannot reproduce this.

I have created a repository and then added a collaborator with write access - they cannot access the repository settings page.
I have created a repository and then added a team with write access - members of this team cannot access the repository settings page.

Prohibit users from creating their own repositories and forking others. Work should only be done on existing repositories. They can only be created and managed by the system administrator.

I'm fairly certain that there is another feature request for setting hard limits on the number of forks but I can't find it right now.

However if you limit forks users may have difficulty creating PRs (except through the agit system.)

@zeripath commented on GitHub (Apr 19, 2022): > A user with write access has access to the "Danger Zone" section, this is very dangerous, he can delete the repository, wiki and other important data. As @lunny writes above I cannot reproduce this. * I have created a repository and then added a collaborator with write access - they cannot access the repository settings page. * I have created a repository and then added a team with write access - members of this team cannot access the repository settings page. > Prohibit users from creating their own repositories and forking others. Work should only be done on existing repositories. They can only be created and managed by the system administrator. I'm fairly certain that there is another feature request for setting hard limits on the number of forks but I can't find it right now. However if you limit forks users may have difficulty creating PRs (except through the agit system.)

GiteaMirror commented

2025-11-02 08:15:14 -06:00

@KarenArzumanyan commented on GitHub (Sep 7, 2022):

A user with write access has access to the "Danger Zone" section, this is very dangerous, he can delete the repository, wiki and other important data.

As @lunny writes above I cannot reproduce this.

Okay, I'll test again.

I have created a repository and then added a collaborator with write access - they cannot access the repository settings page.

I have created a repository and then added a team with write access - members of this team cannot access the repository settings page.

Prohibit users from creating their own repositories and forking others. Work should only be done on existing repositories. They can only be created and managed by the system administrator.

I'm fairly certain that there is another feature request for setting hard limits on the number of forks but I can't find it right now.

However if you limit forks users may have difficulty creating PRs (except through the agit system.)

No, I have users without forks and they can pull requests.
I need to prevent everyone from forking. They can do pool requests and that's enough.
This is very important from a security point of view. To prevent users from transferring rights in the Gitea to their forks, to other users.

@KarenArzumanyan commented on GitHub (Sep 7, 2022): > > A user with write access has access to the "Danger Zone" section, this is very dangerous, he can delete the repository, wiki and other important data. > > As @lunny writes above I cannot reproduce this. Okay, I'll test again. > > * I have created a repository and then added a collaborator with write access - they cannot access the repository settings page. > * I have created a repository and then added a team with write access - members of this team cannot access the repository settings page. > > > Prohibit users from creating their own repositories and forking others. Work should only be done on existing repositories. They can only be created and managed by the system administrator. > > I'm fairly certain that there is another feature request for setting hard limits on the number of forks but I can't find it right now. > > However if you limit forks users may have difficulty creating PRs (except through the agit system.) No, I have users without forks and they can pull requests. I need to prevent everyone from forking. They can do pool requests and that's enough. This is very important from a security point of view. To prevent users from transferring rights in the Gitea to their forks, to other users.

GiteaMirror commented

2025-11-02 08:15:14 -06:00

@wxiaoguang commented on GitHub (Mar 29, 2023):

I need to prevent everyone from forking. They can do pool requests and that's enough.

I guess this request could be useful for some users. Is it resolved? Or not planed?

@wxiaoguang commented on GitHub (Mar 29, 2023): > I need to prevent everyone from forking. They can do pool requests and that's enough. I guess this request could be useful for some users. Is it resolved? Or not planed?

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#8710