Repository navigation
Description
Affected versions: confirmed on commit 553e6cf2b22a981c8eb9203304aff8acee159dc2 (HEAD of the default branch, latest tag v3.0.0).
Summary
The console's authorization gate, Account.CheckPermission, has exactly one implementation wired into the server, and it unconditionally returns success regardless of the operation, whether it is a mutation, or the caller's identity. Any authenticated user, including one explicitly configured with the lowest tier and zero permissions, has full administrative control over every operational resource the console manages.
Details
console/account/account-default.go:
func (d *DefaultAccount) CheckPermission(pre string, isEdit bool, userID int) (bool, error) {
if isEdit {
return true, nil
}
return true, nil
}This is the only type in the entire codebase implementing the Account interface's CheckPermission method. app/console/router.go registers one package-level factory built from this implementation, and every module's routes (project, apis, cluster, node, strategy, plugin, balance, etc.) are wired through that same factory, so every mutating console endpoint inherits this stub. goku-handler/account.go's AccountHandler.ServeHTTP calls a working CheckLogin first (authentication is intact), then this broken CheckPermission (the authorization step) before passing the request through. There is no second authorization layer anywhere else in the request path.
The data model for a permission ceiling exists in this same codebase and is populated correctly: goku_admin.userType (0 = super-admin, 1 = admin, 2+ = custom role) and a per-user permissions JSON map, correctly consulted by the read-only /user/checkIsAdmin//user/checkIsSuperAdmin endpoints. It is simply never consulted by the permission-gating path that every mutating operation goes through.
Steps To Reproduce
(available upon request)
Impact
Any authenticated console user, regardless of configured role or permissions, has full administrative control over every operational resource the console manages (projects, APIs, strategies, plugins, nodes, clusters). The only boundary in the system is whether a request is authenticated at all; once authenticated, there is no privilege ceiling of any kind.
Activity