Hello @soloestoy, thanks for the PR, certain changes make sense to me, other look a bit too strict, for instance in some instance it is good that Lua scripts can call administrative commands. I guess that in the case of TTL you wanted to add R because the master and the slave cannot return this information in a consistent way? Btw I'll can the list item per item and comment accordingly. Thanks.

Hello @antirez

I guess that in the case of TTL you wanted to add R because the master and the slave cannot return this information in a consistent way?

Yes, the TTL is a problem.

for instance in some instance it is good that Lua scripts can call administrative commands

Maybe slowlog can be allowed.

But shutdown, bgsave, config and bgrewriteaof should not be allowed I think, because these commands executed in a lua script may lead to data inconsistency between AOF and memory:

1. bgrewriteaof should not be allowed in scripts, just see the case below:

   127.0.0.1:6379> del a
   (integer) 1
   127.0.0.1:6379> config set appendonly yes
   OK
   127.0.0.1:6379> eval "redis.call('incr','a') redis.call('bgrewriteaof')" 0
   (nil)
   127.0.0.1:6379> get a
    "1"
   127.0.0.1:6379> debug loadaof
   OK
   127.0.0.1:6379> get a
   "2"
   

   We can see that after reload aof, key a has different value, that's because command incr a in lua script has already been executed and then bgrewriteaof will persist the key-value pair to AOF file, and then the whole script will be stored in AOF file too, it means that incr command has been stored twice.

2. config should not be allowed in scripts, because config set appendonly yes may trigger AOF rewrite.

3. bgsave should not be allowed in scripts, because it may get different reply if there are child process saving RDB/AOF or not.

4. shutdown should not be allowed in scripts, because EXEC may be lost in AOF file if we use redis.replicate_commands(). And this will break scripts' atomicity.

Thank you @soloestoy, merged.

Oops.. this PR is too old, I just wanna update it but you merged it before that @antirez , just open another PR #5296.

@soloestoy no problem , just merged the other one as well :-) Thanks

We have another problem about random write commands... @antirez see PR #5208.