The @read and @write ACL categories do not currently include select. This may be very confusing and may lead to non-obvious outcomes, since specifying the correct database is a fundamental requirement of successful read and write operations, and can lead to confusion, as demonstrated by tickets like this where the user had configured:
ACL SETUSER cacheUser on >myPass ~AppCache* -@all +@pubsub +@read +@write +echo +info +SET +GET +eval +ping
In the above case, the -@all @read +@write had the effect that GET, SET etc worked, but the SELECT did not, causing activity to happen incorrectly on DB0. Obviously a workaround here is to add +select, but I propose that this should be implicit in @read / @write.
Additional: I note that select is in @keyspace (which also includes things like flushdb, so: use-with-caution). I do not know whether there are implementation details that may cause problems such as "a command can only be in a single ACL category" (edit: upon further investigation I do not believe this to be a problem - del is in both @write and @keyspace, for example).
One potential gotcha; I do not know the order in which ACLs are applied; if it is left-to-right, then pre-existing setups like +select +@read -@write would presumably (if select was included in @read and @write) lead to not having select. Not sure if this is considered a problem.