The problem/use-case that the feature addresses
If we want to call an script or a function from within a Redis module, we do not have an effective way today of enforcing ACLs on them, as every RM_Call runs as the root user. This new API call would allow us to specify the user/ACL that should be enforced on the call.
Description of the feature
We would take the existing RM_Call implementation and simply add a user pointer to it. RM_Call() would wrap this modified function and simply pass NULL to it for the user pointer.
Module developers would be able to retrieve a user object (using exiting APIs) and pass that object to the new RM_CallWithUser() function and after allocating the tempclient, would assign the passed in user object to that client.
Alternatives you've considered
For regular redis commands we can enforce ACLs themselves before we call RM_Call using existing module APIs. However, functions and scripts are black boxes to us and there doesn't seem any good way to enforce ACLs on Redis commands they issue. We considered using the command filter and redirecting "failed acls" to a "fake" command that simulated an ACL failure, but failing on an ACL isn't the same as failing execution so they shouldn't be treated the same.
Additional information
In practice, this could simplify a lot of module code that has to enforce ACLs themselves even for regular Redis commands as they could just rely on Redis doing it correctly for them.
Comment From: madolson
My understanding was that the idea was to have users use https://redis.io/docs/reference/modules/modules-api-ref/#redismodule_aclcheckcommandpermissions like APIs to check if a command could be executed. ACLCheckCommandPermissions should do the full permission checks, so you can call it before RM_Call() and then react accordingly.
Comment From: oranagra
@madolson IIUC, he's arguing that he can easily do that for any command he's executing, other than EVAL.
Comment From: oranagra
@MeirShpilraien @yossigo WDYT?