-
Notifications
You must be signed in to change notification settings - Fork 927
Add ValkeyModule_ACLCheckCommandPermissionsForCurrentUser API #2690
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: unstable
Are you sure you want to change the base?
Conversation
Introduces a new module API function that allows modules to check if a command can be executed by the current module context user according to ACL rules. This function provides a convenient wrapper around the existing `ValkeyModule_ACLCheckCommandPermissions` API by automatically using the user associated with the module context, eliminating the need for modules to manually retrieve the user. This addition simplifies ACL permission checking for modules that need to validate commands against the current context user. Signed-off-by: Ricardo Dias <[email protected]>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## unstable #2690 +/- ##
============================================
+ Coverage 72.18% 72.54% +0.35%
============================================
Files 128 128
Lines 71037 71254 +217
============================================
+ Hits 51277 51690 +413
+ Misses 19760 19564 -196
🚀 New features to boost your workflow:
|
|
Awesome! Definitely useful in terms of #2309 :) |
Signed-off-by: Ricardo Dias <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a convenience function equivalent (modulo minor details) to this code:
ValkeyModuleString *username = ValkeyModule_GetCurrentUserName(ctx);
ValkeyModuleUser *user = ValkeyModule_GetModuleUserFromUserName(username);
return ValkeyModule_ACLCheckCommandPermissions(user, argv, argc);Is this correct? If it's already possible to do this from a module, then why add this? Performance or just convenience?
It's correct, but the |
Signed-off-by: Ricardo Dias <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a convenience function equivalent (modulo minor details) to this code:
ValkeyModuleString *username = ValkeyModule_GetCurrentUserName(ctx); ValkeyModuleUser *user = ValkeyModule_GetModuleUserFromUserName(username); return ValkeyModule_ACLCheckCommandPermissions(user, argv, argc);Is this correct? If it's already possible to do this from a module, then why add this? Performance or just convenience?
It's correct, but the
ValkeyModule_GetModuleUserFromUserNamefunction allocates memory, which will introduce a performance penalty in the lua code that calls commands. Therefore, it's not just for convenience, it's mainly about performance.
OK, good to know.
Maybe it's not a bottleneck but temporary allocations like this are always annoying. It's a sign of a suboptimal API, I suppose.
Signed-off-by: Ricardo Dias <[email protected]>
Signed-off-by: Ricardo Dias <[email protected]>
Signed-off-by: Ricardo Dias <[email protected]>
Signed-off-by: Ricardo Dias <[email protected]>
| if (ctx == NULL) { | ||
| errno = EINVAL; | ||
| return VALKEYMODULE_ERR; | ||
| } else if (ctx->user == NULL && (ctx->client == NULL || ctx->client->user == NULL)) { | ||
| errno = ENOTSUP; | ||
| return VALKEYMODULE_ERR; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM
Signed-off-by: Ricardo Dias <[email protected]>
| ValkeyModuleUser user = { | ||
| .user = ctx->client->user, | ||
| .free_user = 0, | ||
| }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This entire API is because we're trying to bypass the allocation and do it on the stack here. When the API was written, we cared more about abstraction then performance. If we think performance is so critical, I would rather just ditch the abstraction and directly return the user from the module APIs.
Glancing through the code I don't see any incompatibility with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you proposing to make ValkeyModuleUser a type alias to user?
In that case we would probably need to add a field in the user struct to distinguish between users created by modules, and users created in the core.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case we would probably need to add a field in the user struct to distinguish between users created by modules, and users created in the core.
Yes. We don't expect a large number of users, so adding an extra field should be safe. I think we even have a bit field we could use if we wanted to avoid adding any memory at all.
Introduces a new module API function that allows modules to check if a command can be executed by the current module context user according to ACL rules.
This function provides a convenient wrapper around the existing
ValkeyModule_ACLCheckCommandPermissionsAPI by automatically using the user associated with the module context, eliminating the need for modules to manually retrieve the user.This addition simplifies ACL permission checking for modules that need to validate commands against the current context user.