8000 console permission check is an unconditional-true stub · Issue #114 · eolinker/goku_lite · GitHub
[go: up one dir, main page]

Skip to content

console permission check is an unconditional-true stub #114

Open

Description

@carfeii

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      0