We have an internal use case at AWS which wants to build a module that blocks all write access to a defined set of keys, but still allows read access. Basically we want to inject some data and add a guard rail to prevent unintended modification.
One option is to extend the existing ACLs to support deny permissions, but I think that is wrong for two reasons. The first is that is that the module need to manipulate all existing users to remove the permission. The second is that it will show up in stuff like ACL errors, which some folks may monitor against. Instead I will propose the following two simple APIs.
int RedisModule_RestrictKeyPattern(RedisModule *ctx, char *key_pattern, int flags);
int RedisModule_UnrestrictKeyPattern(RedisModule *ctx, char *key_pattern);
When a key pattern is restricted, it will be checked by all users except the super user (admin/aof), and if a key matches any of the restricted patterns with the provided flags it will be denied by a custom MODULE RESTRICTED reason. This will require some minor tweaks to the ACL code.
Note with flags, a module may restrict both Read and write permissions. (Or just READ permissions I suppose)
Comment From: oranagra
this seems very (too) specific. i think we should think of something more generic.
p.s. maybe a command filter together with keyspecs can handle it in some way.
Comment From: madolson
@oranagra We looked into the filtering, and it has the two gaps: 1. You can't easily extract the keys being accessed by a command. 2. It can't easily deny a command, since it has to rewrite it.
We could fix these gaps, but it seems like retrofitting it for the wrong use case.
We could introduce something like a command "before" interceptor that acts kind of like a filter (or validator), but doesn't allow changing the contents of the command. I think that generally solves the same use case.