Skip to content

Sort out the mess of modules, channels, keyspecs, and ACLs #10156

@madolson

Description

@madolson

This is an issue that was discovered while implementing ACL V2. The end result of this will be we can declare channels from module keyspecs that are checked by ACLs, and not require module developers to explicitly do ACL checks for channels.

In the current implementation, ACLs relies on keyspecs for determining which keys are being accessed and hardcodes which channels are accessed and which commands access them. This means that modules can declare keys that are checked by ACLs, but doesn't allow them to define channels that are checked.

The reason we can't use the existing keyspecs to access the channels is that:

  1. Only shard channels are declared as keys, not regular channels. This is really just a hack because shard_channels are routed like regular keys are.
  2. Some channel accesses are always allowed, specifically when unsubscribing. There is no way to exempt a key from having a check.

I propose we finalize the following 4 flags.

  1. CHANNEL and CHANNEL_PATTERN: Flags that are used to indicate that a channel or channel pattern is being used instead of a key. Modules can use these to declare channels that will be checked by ACL permissions.
  2. NO_SLOT: Flag used to indicate a key should not be assigned to a slot using the normal cluster routing. This is primarily intended to be used to differentiate shard and normal channels. Setting this flag omits keys from COMMAND GETKEYS and the legacy COMMAND command. I suppose modules could use this for some reason if they want to declare a key which have ACLs checked but may not want to route the command.
  3. Introduce a keyspec called "IGNORE_ACL" to indicate that this key is not checked as part of ACLs. This will handle the unsubscribe case, and modules can use it as well if they want.

@oranagra @yossigo @guybe7 Thoughts?

Metadata

Metadata

Assignees

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