UpdatePermission renames instead of updating metadata (and drops the metadata it is given)

Inizia da internal/api/v1beta1connect/permission.go e confronta UpdatePermission con CreatePermission, quindi segui Update in internal/store/postgres/permission_repository.go. Verifica come vengono gestiti i campi dei metadati e dell’identità e controlla il percorso schema.ValidateCustomPermission indicato. Il lavoro è completato quando gli aggiornamenti preservano l’identità del permesso, rendono persistenti i metadati e rifiutano le chiavi non valide senza interrompere il percorso di reconcile esistente.

What

The UpdatePermission handler (internal/api/v1beta1connect/permission.go) has two problems.

1. It writes name and namespace_name with no grammar check. CreatePermission now runs schema.ValidateCustomPermission, but the update path runs no check at all. It parses the request key into a namespace and a name, then passes them straight to the service. A key that splits into three non-empty parts but breaks the grammar goes through unchecked:

   • resource.Order.get (uppercase)
   • resource.order_item.get (underscore in a part)
   • compute.machine.owner (reserved verb)
   • any key whose flattened service_resource_verb is longer than 64 characters

2. The repository Update (internal/store/postgres/permission_repository.go) only sets name, namespace_name, and updated_at. It never writes metadata. So the metadata the handler builds is dropped. The only thing the endpoint actually changes is the identity, which is a rename.

Why it matters

A rename to a value SpiceDB will not accept still succeeds in Postgres. On the next server boot, MigrateSchema merges every permission row into the SpiceDB schema. The bad row fails to compile, so the server will not start until someone fixes the row by hand.

Scope and risk

Low. The reconciler never calls UpdatePermission. Its client interface has only ListPermissions, CreatePermission, and DeletePermission, and a permission is identity only (added or deleted, never updated). So only a direct API caller can hit this. It is not on the GitOps path.

Suggested fix

Two options:

1. Validate the key. Resolve the key to a namespace and a name and run schema.ValidateCustomPermission before the write, the same as CreatePermission. Minimal, but it still allows a rename to a valid key.
2. Preferred: stop renaming. A permission's identity is fixed once it is created, so the update path should change only metadata. Make the handler and the repository Update write only metadata by id and never touch name or namespace_name. This makes the endpoint do what it claims, drops the dependence on the deprecated name and namespace fields, and fixes the dropped-metadata bug at the same time.

Context

Found during review of the reconcile permission PRs (#1889 added the shared schema.ValidateCustomPermission; #1892 switched the Permission kind to the key form). It was agreed there to track this as a follow-up rather than widen those PRs.