In fact, this is not a bug in a sense, because if we use psub, the parameter should be pattern. But psub should support exact matching. For example, operations like PSUBSCRIBE aa are actually supported. So it can be seen that psub is obviously compatible with sub, but the semantics in acl is different. When psub is detected, it is actually compared verbatim with the existing user->channel. This leads to the failure of the detection here if the parameter of psub is not pattern. For example:

acl setuser default resetchannels
acl setuser default &a*
psubscribe aa

It will fail at this time.

So can we first check whether the psub parameter is pattern, and if not, execute stringmatchlen? @itamarhaber

Comment From: hpatro

I feel like this is a bug, we should be allowing the client to psubscribe to aa channel in the above case. I was trying few other cases like a glob superset set in user acl doesn't respect it's subset in the psubscribe.

127.0.0.1:6379> acl setuser default resetchannels &a*
OK
127.0.0.1:6379> psubscribe aaaa*
Reading messages... (press Ctrl-C to quit)
(error) NOPERM this user has no permissions to access one of the channels used as arguments

Comment From: itamarhaber

Hi @Super-long & @hpatro

Thanks for opening the discussion. This is by design, actually, and you can find the word "literal" in the original PR #7993. The reasoning for not allowing pattern evaluation was, iirc, to reduce complexity. That said, with v7 and ACL v2 around the corner, that decision can be debated :)

Comment From: Super-long

In fact, the following description can also be found in https://redis.io/topics/acl "whereas PSUBSCRIBE requires a literal match between its channel patterns and those allowed for user." I think there are actually two solutions here: 1. The first is to split user->channel into two linked lists, one for the pattern, which we call plink, and the other for the exact match of sub, which we call slink. In this way, we can execute stringmatchlen in slink when psub is not a pattern, and perform verbatim matching like the old method when it is a pattern. This can solve the matching problem when psub is not a pattern. 2. Think of a way to support the matching of two patterns and completely solve the problem.

Comment From: Super-long

In fact, this problem can be solved. The problem can be simplified to The inclusion problem for regular (glob). Related problems can be explained in this paper: 《The inclusion problem for regular expressions》

So do we choose to be simple and tolerate the incompatibility between regulars (the first scheme), or choose to solve the problem completely but introduce complexity (the second scheme)?

I think I can try to complete related work

Comment From: Super-long

What do you think of this problem? @itamarhaber :)