-
Notifications
You must be signed in to change notification settings - Fork 23
ACL RFC for Search module #18
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: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Allen Samuels <[email protected]>
Adding gaps relative to RediSearch section Signed-off-by: yairgott <[email protected]>
Fixing heading of the 'Unsupported knobs and control' section Signed-off-by: yairgott <[email protected]>
removal of links to redis.io Signed-off-by: yairgott <[email protected]>
Signed-off-by: Allen Samuels <[email protected]>
PrefixACL.md
Outdated
VALKEYMODULE_PREFIX_CHECK_READ_ACCESS = 1, | ||
} | ||
|
||
int ValkeyModule_AclCheckKeyPrefixPermissions(ValkeyModuleContext *ctx, const char *prefix, size_t bytes, size_t flags) |
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.
- using ValkeyModuleString* data type eliminates the need for bytes. Also, it seems more aligned with ValkeyModule_ACLCheckKeyPermissions.
- We need to support multiple prefixes and with this interface the caller needs to loop call the this API. Consider extending the API to support variadic arguments where each argument must be a ValkeyModuleString*. .e.g.: int ValkeyModule_AclCheckKeyPrefixPermissions(ValkeyModuleContext *ctx, size_t flags, ...)
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.
Agree that passing in multiple ValkeyModuleStrings so that there need be only a single call is a good idea. A variadic function is difficult to use, rather i'll propose an array with count.
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.
SG!
@@ -0,0 +1,518 @@ | |||
## RFC: 8 |
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.
Added accidentally?
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.
yes
Signed-off-by: Allen Samuels <[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.
should this reside under valkey-search/rfc/ ?
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.
Since this is essentially a proposal to augment the Module API, I assumed that the core team would be more interested in it. (IMO, even though the module call fallback method is fully functional, I'm skeptical that it's really a production solution due to performance concerns).
As requested, an RFC to describe the security model for the search module.
This also proposes a new module API to make the security model enforcement efficient.