ACL behavior on keyless commands about valkey HOT 2 OPEN

As much as I don't like it, I have to say that option 2 is safer. There is just no way to evaluate the risk of "unknown unknowns". That said, I still hope someone would come out and tell me that going with option 1 will actually break them.

Semantically speaking though, there might be a third option for SCAN, RANDOMKEY, and KEYS through (expensive) filtering but that wouldn't work for FLUSHALL and FLUSHDB.

from valkey.

I think we should look these 5 commands in two different sense:

Set 1: SCAN, KEYS, RANDOMKEY
Set 2: FLUSHALL, FLUSHDB

• Set 1 here exposes actual key(s) (data) to an user and is comparable to row level security in DBMS world (https://www.postgresql.org/docs/current/ddl-rowsecurity.html). Hence, I think set 1 should be handled by key permissions.
• Set 2 is command level operation which doesn't expose(s) any data to the user and decision should be taken on basis of command based permissions supported by the user. I would map it to https://www.postgresql.org/docs/current/sql-grant.html

Regarding the option we should proceed with, I feel option 2 is the safer choice but it's confusing with allkeys key permission. How about @keyless/ @nokey category for set 1 and leave the set 2 as is.

from valkey.