Write / Read Permissions for specific units are ignored #1140

Closed
opened 2025-11-02 03:49:51 -06:00 by GiteaMirror · 6 comments
Owner

Originally created by @TheRealPowerCoder on GitHub (Oct 11, 2017).

Description

When using organisations and teams there are permission settings for these teams. Available options are

  • Read Permissions (with units that can be selected below)
  • Write Permissions (with units that can be selected below)
  • Admin Permissions

I created a team called WikiAuthors and only enabled them write access to the wiki. When testing the WikiAuthors could still change files in the code segment, accept pullrequest, etc (see try.gitea above).

When setting WikiAuthors to Read Permission and only for the unit Wiki, they could still see everything else but furtunetly not edit anything (except creating issues and pull requests) (see try.gitea above).

A simmilar problem arises when enableing branch protection. Users of a Team that is not whitelisted can still force push into a protected branch (this was not tested in the try.gitea version).

Am I using the permission system wrong or is it not fully implemented yet?
It seems that Gitea only cares about whether or not at least one write/read permission is set.
This Issue is somewhat related to #2684 as a broader issue concerning the permission system.

Screenshots

Originally created by @TheRealPowerCoder on GitHub (Oct 11, 2017). - Gitea version (or commit ref): 339d7de - Git version: 2.14.1 (Windows) - Operating system: Linux Alpine (Gitea Docker) - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [x] Yes (provide example URL): https://try.gitea.io/SuperOrganisation/PermissionsTest - [ ] No - [ ] Not relevant - Log gist: ## Description When using organisations and teams there are permission settings for these teams. Available options are - Read Permissions (with units that can be selected below) - Write Permissions (with units that can be selected below) - Admin Permissions I created a team called _WikiAuthors_ and only enabled them write access to the wiki. When testing the _WikiAuthors_ could still change files in the code segment, accept pullrequest, etc (see try.gitea above). When setting _WikiAuthors_ to __Read Permission__ and only for the unit __Wiki__, they could still see everything else but furtunetly not edit anything (except creating issues and pull requests) (see try.gitea above). A simmilar problem arises when enableing branch protection. Users of a Team that is not whitelisted can still force push into a protected branch (this was not tested in the try.gitea version). __Am I using the permission system wrong or is it not fully implemented yet?__ It seems that Gitea only cares about whether or not at least one write/read permission is set. This Issue is somewhat related to #2684 as a broader issue concerning the permission system. ## Screenshots <!-- **If this issue involves the Web Interface, please include a screenshot** -->
GiteaMirror added the type/enhancement label 2025-11-02 03:49:51 -06:00
Author
Owner

@Morlinest commented on GitHub (Oct 11, 2017):

I think everyone can see everything because your org and repo is public. Try to make repository private first.

@Morlinest commented on GitHub (Oct 11, 2017): I think everyone can see everything because your org and repo is public. Try to make repository private first.
Author
Owner

@TheRealPowerCoder commented on GitHub (Oct 11, 2017):

I have tried your suggestion that setting the repo to private might change things. Yes it does work for read permissions. It makes sense that everybody can see everything if the repo is public.

However write permissions on the other hand are still problematic. Unless the repo is set to private, the unit settings will be ignored and everyone with at least one write permission has repo wide write access. Our repo has to be public but with units affecting write permissions, as I dont want everybody to have access for writing in the Wiki or creating releases.

As it stands now my original issue still exists: Unit Write Permissions dont affect access level unless repo is made private. If the repo is private I am unable to say that WikiAuthors have write access to the wiki and still are able to__read__ otherparts of the repo.

Seperate read and write unit permissions with at least write permissions still being affective in public repos could solve the issue.

@TheRealPowerCoder commented on GitHub (Oct 11, 2017): I have tried your suggestion that setting the repo to private might change things. Yes it does work for read permissions. It makes sense that everybody can see everything if the repo is public. However write permissions on the other hand are still problematic. Unless the repo is set to private, the unit settings will be ignored and everyone with at least one write permission has repo wide write access. Our repo has to be public but with units affecting write permissions, as I dont want everybody to have access for writing in the Wiki or creating releases. As it stands now my original issue still exists: Unit Write Permissions dont affect access level unless repo is made private. If the repo is private I am unable to say that _WikiAuthors_ have write access to the wiki and still are able to__read__ otherparts of the repo. __Seperate read and write unit permissions with at least write permissions still being affective in public repos could solve the issue.__
Author
Owner

@lunny commented on GitHub (Oct 15, 2017):

I think the problem is we want some team could

read code and write wiki

or something like this.
Now we only support Read or Write all team's Units.
This should be an enhancement of team settings.

@lunny commented on GitHub (Oct 15, 2017): I think the problem is we want some team could > read code and write wiki or something like this. Now we only support Read or Write all team's Units. This should be an enhancement of team settings.
Author
Owner

@terrywh commented on GitHub (Nov 28, 2018):

are there any news on this ? is this related to #5308 / #5307 ?

@terrywh commented on GitHub (Nov 28, 2018): are there any news on this ? is this related to #5308 / #5307 ?
Author
Owner

@lunny commented on GitHub (Nov 28, 2018):

This should be fixed by #5314

@lunny commented on GitHub (Nov 28, 2018): This should be fixed by #5314
Author
Owner

@lunny commented on GitHub (Nov 28, 2018):

Please feel free to reopen.

@lunny commented on GitHub (Nov 28, 2018): Please feel free to reopen.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#1140