Feature request type

enhancement

Is your feature request related to a problem? Please describe

Garnet's ACL system tracks per-command permissions in a fixed-size bitmap indexed by RespCommand. Built-in commands fit this model cleanly, but custom (extension) commands have RespCommand IDs assigned dynamically at module load and live outside the bitmap's range.

The practical effect is that ACL rules cannot reference individual custom commands. The only knob available today is the all-or-nothing +@custom category, which either grants access to every loaded custom command or to none of them. There is no way to express a rule like +json.set or -json.get for a specific extension command.

This makes it difficult to grant scoped access to custom commands in any deployment that has more than one custom command and more than one role. For example, a read-only role cannot be granted JSON.GET while being denied JSON.SET without also affecting every other extension command on the server.

Describe the solution you'd like

Introduce per-name allow/deny entries on the user's permission set, stored alongside the existing command bitmap. Teach the ACL parser to accept custom command names as first-class tokens, and have dispatch for custom commands consult the per-name entries before falling back to the bitmap.

Expected behavior:

• ACL SETUSER alice +json.get -json.set should grant alice access to JSON.GET while denying JSON.SET, independent of any category-level rule.
• An explicit per-name deny (-name) should beat a category-level allow (+@custom, +@all), matching the precedence model that Redis uses for built-in commands.
• ACL file load should remain robust to module-load order: a file that references a custom command whose module has not yet loaded should not break startup. An opt-in strict mode can be offered for operators who want startup-time typo protection.
• ACL SETUSER issued at runtime should be strict, since modules are already loaded by then.

Happy to put up a PR for this if the direction seems reasonable.

Describe alternatives you've considered

• Keep using +@custom and rely on module-level separation. This forces an all-or-nothing trust boundary per server and doesn't compose with multi-role deployments.
• Mint static RespCommand IDs for known modules so they fit the existing bitmap. This couples the ACL system to a fixed module set and breaks the dynamic-loading model.

Additional context

No response