feat: Add configurable permissions for Actions automatic tokens

[Excellencedev]

Summary

Implements Issue #24635 - Support configuring permissions of automatic tokens for Actions jobs.

This PR adds the ability to configure the default permissions granted to the GITHUB_TOKEN when running workflow jobs in a repository. Users can now choose between:

• Permissive mode (default): Workflows have read and write permissions for all scopes (backwards compatible with existing behavior)
• Restricted mode: Workflows have read-only permissions by default

Changes

Backend

• Extended ActionsConfig struct in models/repo/repo_unit.go with:

  • ActionsTokenPermissionMode type (permissive/restricted)
  • ActionsTokenPermissions struct for per-unit permissions (Contents, Issues, PullRequests, Packages, Actions, Wiki)
  • Helper methods for getting effective permissions and clamping

• Modified GetActionsUserRepoPermission in models/perm/access/repo_permission.go to use configurable per-unit permissions instead of hardcoded access modes

• Added UpdateTokenPermissions handler in routers/web/repo/setting/actions.go

Frontend

• Added Token Permissions UI section in repository Settings → Actions → General
• Added locale strings in options/locale/locale_en-US.ini

Tests

• Added unit tests in models/repo/repo_unit_test.go for token permission methods
• Added integration test TestActionsTokenPermissionsModes in tests/integration/actions_job_token_test.go

Screenshots

The new Token Permissions section appears in Settings → Actions → General:

• Radio buttons for Permissive/Restricted mode
• Warning note about fork PRs always being read-only

Notes

• Fork pull requests always receive read-only access regardless of settings (security feature)
• Default behavior is "permissive" for backwards compatibility
• No database migration required - settings stored as JSON in existing repo_unit config

Related Issues

Closes #24635
/claim #24635

[Excellencedev]

@lunny @wxiaoguang Please review this

[wxiaoguang]

Thank you for asking me to review, but I don't use Actions. You can invite the maintainers from the original issue to review.

[Excellencedev]

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

[silverwind]

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.

[Excellencedev]

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

[wxiaoguang]

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

[Zettat123]

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.

[silverwind]

Issues I see on this screenshot:

• Header text is black on dark theme
• Contrast on light text is too low

I can probably help fix those, the first one may be a missing override of the fomantic CSS.

[Excellencedev]

@Zettat123 @silverwind Pls give me a few hours(15-20 hours) and this PR will be ready to go
I will make sure to address all your comments and make sure I do everything from the issue
Drafting until then
When it is done, I will undraft it and notify you

[wxiaoguang]

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.

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?

[Excellencedev]

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.

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 ?

[wxiaoguang]

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.

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.

[Zettat123]

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.

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?

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.

[silverwind]

Imho, the only sensible thing we can do is race these 2 PRs.

[Excellencedev]

Adressed most your comments in my latest commit, now i just need to make sure i fully implement the proposal in #24635

[Zettat123]

According to the solution in #24635, I think this PR does not implement:

• Support configuring the permissions
• Support configuring access between repositories
• Private packages can be accessed by Actions only when they have been linked to repositories

[Excellencedev]

@Zettat123 It should look okay now

[Excellencedev]

@Zettat123 Weird, I thought CI automatically fails on any unused stuff

But don't worry I'll remove those functions

[Excellencedev]

@Zettat123 I've addressed all your comments

[Excellencedev]

@Zettat123 Added the test and it passes

[Excellencedev]

@Zettat123 Addressed your comment. You can approve this PR or drop more review comments

[Zettat123]

Thanks for the update. I’ve tested the new feature and it works fine on my end. However, I think there are still some issues.

1. On the permissions configuration page, users should only be able to select one of the following three modes:

• Read and write permissions (permissive)
• Read repository contents and packages permissions (restricted)
• Custom Maximum Permissions

If the user selects the first or second option, the table for configuring maximum permissions should be disabled. Only when the user selects the third option should they be able to configure permissions within the table.

2. If the repository belongs to an organization, an option should be available to "Follow the organization-level configuration." When this option is selected, all three of the modes cannot be disabled.

3. Users should still be able to specify permissions in the workflow file that do not exceed the configured maximum. For instance, even if the repository's actions permission mode is set to permissive, the GITEA_TOKEN's permission for contents remains Read-Only in the following workflow file:

...
permissions:
  contents: read
...

4. For cross-repository access within the same organization, permissions are currently limited to an "Cross-Repository Access" configuration (where all repositories can access each other). As described in the proposal, we should support a selective access policy for specific repositories.

Current:

Proposal:

5. The GITEA_TOKEN should be restricted to accessing only those packages linked to repositories.

Private packages can be accessed by Actions only when they have been linked to repositories

However, in the "Cross-Repo Package Access" test, the token is able to access the package even though the package hasn't been linked to a repository.

[Excellencedev]

@Zettat123 I have addressed the remaining issues as follows:

1. Permission Configuration Modes

I've updated the UI logic to strictly enforce single selection among the three modes:

• Permissive: Read/Write access.
• Restricted: Read-only access to repository contents and packages.
• Custom: Explicitly configured maximum permissions.

2. "Follow Organization Configuration"

I've implemented the Follow Org Config checkbox for organization-owned repositories.

• When checked, the repository inherits the Organization's TokenPermissionMode and MaxTokenPermissions.
• The local configuration UI is completely disabled in this state to prevent confusion.
• Backend logic (GetActionsUserRepoPermission) now transparently loads the organization's configuration when this flag is set.

3. Workflow File Permissions

I've verified the interaction between the configured maximums and the workflow file permissions: key.

• The configured maximum permissions acts as a hard ceiling (clamping).
• The workflow file can further restrict permissions (e.g., asking for read when write is allowed), but it cannot elevate them beyond the maximums.
• This ensures the GITEA_TOKEN never has more privileges than what is configured in the settings, regardless of what the workflow requests.

4. Selective Cross-Repository Access

I've replaced the "Allow Cross-Repository Access" toggle with a granular system:

• Admins can now choose between "All Repositories" or a specific "Allowed Repositories" list.
• An interactive UI allows searching for and adding/removing specific repositories to the allowed list.
• The backend GetActionsUserRepoPermission now checks this list before granting access.

5. Package Access Restrictions

I've tightened the package access rules in reqPackageAccess:

• Unlinked Packages: Access is now explicitly denied for organization packages that are not linked to any repository (packageRepoID == 0).
• Cross-Repo Access: Access to packages in other repositories now strictly respects the cross-repository access policy (either "All" or the specific allow-list).
• This ensures that a token from Repo A cannot access a package in Repo B unless Repo B is explicitly allowed.

[Zettat123]

@Excellencedev Thanks for addressing my comments and providing the fix. I don't have time to test this PR at the moment, but I'll be able to get to it in a few days.

Anyone else who’s available is more than welcome to review this PR and leave their comments.