-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
feat: Add configurable permissions for Actions automatic tokens #36173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
@lunny @wxiaoguang Please review this |
|
Thank you for asking me to review, but I don't use Actions. You can invite the maintainers from the original issue to review. |
@silverwind Please review |
|
I review mostly frontend stuff and am not much of an actions user myself, so please be patient until someone finds time to review it properly. |
No problem |
|
By the way, I see another (older) PR: Feat/actions token permissions #36113 , it added more than 2000 lines of code. What are the differences? Which PR would win ....... @Zettat123 |
This PR doesn't fully implement the proposal in #24635. (For example, it doesn't support configuring actions access between repositories in the same organization) It seems that #36113 implemented these features, but I think its code needs improvement. |
|
@Zettat123 @silverwind Pls give me a few hours(15-20 hours) and this PR will be ready to go |
But "PR: Feat/actions token permissions #36113" came first, and it is more complete, why not respect the first author, but only review this second one? |
@wxiaoguang should i close my pr ? |
I don't know. Reviewers decide. |
I reviewed both PRs, but did not receive responses to my comments in #36113. If @Excellencedev will address the review comments, I think we should keep this PR. |
|
Imho, the only sensible thing we can do is race these 2 PRs. |
|
Adressed most your comments in my latest commit, now i just need to make sure i fully implement the proposal in #24635 |
|
According to the solution in #24635, I think this PR does not implement:
|
|
@ChristopherHX pls review...thanks |
Banning contents for workflows stored in .gitea sounds like reasonable approach for me, but could still force users to update their workflows as it has been ignored for years. (Could be done by schema checking and rejecting the workflow run if contents is present then show an run start failure. Pointing to docs.) (I had already started Schema Checking in nektos/act, just need a permissive schema for gitea that only covers permissions for now) In .github folder I prefer contents to remain consistent with GitHub. Need to allocate some time to go through this PR. |
|
@ChristopherHX Is what I did here okay 28dff2a ? |
My problem with is that result.Releases and result.Code could already be set to a lower value explicitly. If we agree to not allow running such workflow then the code here could be kept. A schema could also mention either releases and code or contents is valid. Currently you could mix them without contents having a lower priority in your parsing code. |
|
I've refactored the parser to implement priority: contents is applied first, then granular scopes like |
|
@ChristopherHX @Zettat123 I added a docs update for this PR: https://gitea.com/gitea/docs/pulls/318 |
|
I found a TODO in gitea/services/context/package.go Lines 95 to 105 in f9d3983
|
eebb54f to
a5debd9
Compare
@Zettat123 fixed f8a0b25 |
|
ready for another review @Zettat123 |
|
@Zettat123 @ChristopherHX pls review this |
| TokenPermissionMode ActionsTokenPermissionMode `json:"token_permission_mode,omitempty"` | ||
| // DefaultTokenPermissions defines the specific permissions for workflow tokens when TokenPermissionMode is set to "custom" | ||
| // and no "permissions" keyword is defined in the workflow YAML. | ||
| DefaultTokenPermissions *ActionsTokenPermissions `json:"default_token_permissions,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reviewed the code. If I understand correctly, the steps you listed are for MaxTokenPermissions, not DefaultTokenPermissions. I'm still not sure what DefaultTokenPermissions actually does. If it's a necessary field, we need a form to configure it on the UI. If not, we should remove it.
|
Based on the recent comments, it appears that the current implementation still contains logical inconsistencies and redundant code. This suggests that the PR requires a more thorough analysis of the existing code and a more comprehensive integration of the review comments provided so far. To ensure we use everyone’s time effectively, I am converting this PR back to Draft status. Since maintainer resources are limited, we expect contributors to perform a rigorous self-review before requesting a formal review. Please ensure the logic is fully closed, redundant elements are removed, and similar issues throughout the PR are addressed consistently. While I would like to help move this PR forward, I am currently tied up with several urgent tasks and do not have the bandwidth to review a PR of this size at this moment. Once you feel the PR is truly ready and you have switched the status back to "Ready for review," I welcome other reviewers to review this PR and provide their feedback. I would appreciate any comments on this. |
|
Okay understood but I hope this PR won't just amount to nothing as it's been open for almost a month with several review comments from different maintainers I will work throughout next week to make this "reviewable" an snake sure maintainers have a good time reviewing this I just hope other maintainers will have on this in the future also |

Overview
This PR introduces granular permission controls for Gitea Actions tokens (
GITEA_TOKEN), aligning Gitea's security model with GitHub Actions standards while maintaining compatibility with Gitea's unique repository unit system.It addresses the need for finer access control by allowing administrators and repository owners to define default token permissions, set maximum permission ceilings, and control cross-repository access within organizations.
Key Features
1. Granular Token Permissions
permissions:keyword in workflow and job YAML files (e.g.,contents: read,issues: write).contentsandpackages, with no access to other units.2. Organization & Repository Settings
3. Security Hardening
4. Technical Implementation
action_run_jobtable. This ensures the token's authority is deterministic throughout the job's lifecycle.contentsscope is applied first, allowing granular scopes likecodeorreleasesto override it for precise control.How to Test
go test ./services/actions/...andgo test ./models/repo/...to verify parsing logic and permission clamping.tests/integration/actions_job_token_test.gocovering:permissions:keyword evaluation.GITEA_TOKENcapabilities.Documentation
Added a PR in gitea's docs for this : https://gitea.com/gitea/docs/pulls/318
/fixes #24635
/claim #24635