Skip to content
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

chore(acl): Implicit categories #3411

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

dranikpg
Copy link
Contributor

My weekly cleanup idea. Most of our CO:: categories became meaningless with the introduction of acl. For example, CO::FAST literally doesn't mean anything, it's never read or used.

The two options are either removing outdated categories or using the rules for acl category deduction:

https://github.com/redis/redis/blob/93fb83b4cb5090b7b48f5466924237558685b811/src/server.c#L3008

@dranikpg dranikpg requested a review from kostasrim July 30, 2024 19:38
@kostasrim
Copy link
Contributor

@dranikpg acl_fam unit failing

Signed-off-by: Vladislav Oleshko <[email protected]>
if (mask & CO::BLOCKING)
out |= acl::BLOCKING;

if ((out & acl::FAST) == 0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A counter example to this is HGETALL which we mark as:

<< CI{"HGETALL", CO::FAST | CO::READONLY, 2, 1, 1, acl::kHGetAll}.HFUNC(HGetAll)

which according to the rules above would mark it as FAST instead of SLOW.

My concern here is that we have to manually check all of these commands and the CO:: variants actually do map to the rules implemented in ImplicitAclCategories (and if the above mapping has no mistakes as well)

Another concern I have is that if we have bugs in our CO:: variants the Implicit rules describe above will insert a bugs in our ACL rules.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another concern I have is that if we have bugs

You can apply that concern to any code, I've added an option to return acl categories from COMMAND, so we can compare before and after and see the differences

before.txt

A counter example to this is HGETALL which we mark as:

It's not a counter example, we just remove CO::FAST. Again, the CO tags don't mean anything now

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, in fact a diff on this will also hinter any errors. I like that

<< CI{"SETRANGE", CO::WRITE | CO::FAST | CO::DENYOOM, 4, 1, 1, acl::kSetRange}.HFUNC(SetRange)
<< CI{"CL.THROTTLE", CO::WRITE | CO::DENYOOM | CO::FAST, -5, 1, 1, acl::kClThrottle}.HFUNC(
ClThrottle);
registry->StartFamily(acl::STRING);
Copy link
Contributor

@kostasrim kostasrim Jul 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can create a class template that is implicitly convertible to CommandId and during that conversion it injects the acl family like acl::STRING here which will move away the logic from registry. But IMO I am mostly worried about correctness than syntactic sugar

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants