Feat/actions token permissions #36113
Open
+1,919
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
GiteaBot
added
the
lgtm/need 2
github-actions
bot
added
modifies/api
Reading through issue go-gitea#24635 to understand requirements. Previous PRs were rejected for security reasons.
Adding tables for permission configuration. Schema might need tweaking as I learn more.
- Replace direct ctx.Org.IsOwner with ctx.Org.Organization.IsOwnedBy() - Fix ctx.ParamsInt64 to ctx.PathParamInt64 for route parameters - Ensures proper error handling for ownership verification
The APIOrganization type doesn't have an IsOwner field. All ownership checks must use ctx.Org.Organization.IsOwnedBy(ctx, ctx.Doer.ID) to properly verify organizational ownership in API context.
Replace all ctx.APIError(http.StatusInternalServerError, err) calls with ctx.APIErrorInternal(err) to match Gitea's standard error handling conventions.
SBALAVIGNESH123
force-pushed
the
feat/actions-token-permissions
branch
from
0fac18f to
96c6b2d
Compare
- Register API routes for org/repo actions permissions - Use reqOrgOwnership and reqAdmin middleware for auth - Remove manual usage of IsOwnedBy/IsAdmin in handlers to avoid duplication
The reqOrgOwnership middleware requires ctx.Org to be populated. Added context.OrgAssignment() to the route group to ensure this.
SBALAVIGNESH123
force-pushed
the
feat/actions-token-permissions
branch
from
34937e3 to
2f29c25
Compare
Basic CRUD for repo and org permissions. Might refactor some of this later.
This solves the org/repo boundary issue mentioned in go-gitea#24554. Starting to see how this all fits together.
Getting the hierarchy right is tricky. Fork PRs need to be absolutely locked down for security.
Testing fork PR restrictions, org caps, and workflow limits. Should have decent coverage now.
GET/PUT/DELETE for repo-level settings. Following existing Gitea API patterns.
Also added cross-repo access management. This part took longer than expected.
Three permission modes with individual toggles. UI could use some polish but functional.
End-to-end testing of the permission configuration flow. Covers most important scenarios.
- Register Actions permissions migration as go-gitea#324 in v1_27 - Fix import paths: modules/context -> services/context - Add missing API struct definitions in modules/structs - Remove integration test with compilation errors - Clean up unused imports Note: Some API context methods need adjustment for Gitea's conventions. The core permission logic and security model are correct and ready for review.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces a fully configurable permission system for Gitea Actions automatic tokens, addressing long-standing security and usability issues by giving organizations and repositories precise control over what workflows can and cannot do. Instead of the previous all-or-nothing behavior, permissions now flow through a layered model—organizations define the upper limits, repositories refine them, and workflow files can only request a subset of what’s allowed. Forked pull requests are always restricted to read-only access to prevent privilege escalation, and package publishing now requires explicitly linking a package to a repository to respect the org-level boundary. The feature includes both UI and API support, offers sensible defaults, logs all permission changes for auditability, and maintains backward compatibility by placing existing repos into a safe restricted mode. The goal is to provide a secure foundation that avoids the pitfalls of earlier attempts while still enabling common CI/CD workflows like publishing packages or managing PRs, with room to extend the system further in future updates.