2021-09-23 01:52:56 -04:00
set testmodule [ file normalize tests/ modules/ aclcheck.so]
start_server { tags { " m o d u l e s a c l " } } {
r module load $testmodule
test { test module check acl for command perm} {
# by default all commands allowed
assert_equal [ r aclcheck.rm_call.check.cmd set x 5 ] OK
# block SET command for user
r acl setuser default - set
catch { r aclcheck.rm_call.check.cmd set x 5 } e
assert_match { * DENIED CMD* } $e
# verify that new log entry added
set entry [ lindex [ r ACL LOG] 0 ]
assert { [ dict get $entry username] eq { default } }
assert { [ dict get $entry context] eq { module } }
assert { [ dict get $entry object] eq { set } }
2022-04-12 01:16:17 -04:00
assert { [ dict get $entry reason] eq { command } }
2021-09-23 01:52:56 -04:00
}
test { test module check acl for key perm} {
2022-01-26 14:03:21 -05:00
# give permission for SET and block all keys but x(READ+WRITE), y(WRITE), z(READ)
2022-01-20 16:05:27 -05:00
r acl setuser default + set resetkeys ~ x % W~ y % R~ z
assert_equal [ r aclcheck.set.check.key " * " x 5 ] OK
catch { r aclcheck.set.check.key " * " v 5 } e
assert_match " * D E N I E D K E Y * " $e
2022-02-22 04:00:03 -05:00
assert_equal [ r aclcheck.set.check.key " ~ " x 5 ] OK
assert_equal [ r aclcheck.set.check.key " ~ " y 5 ] OK
assert_equal [ r aclcheck.set.check.key " ~ " z 5 ] OK
catch { r aclcheck.set.check.key " ~ " v 5 } e
assert_match " * D E N I E D K E Y * " $e
2022-01-20 16:05:27 -05:00
assert_equal [ r aclcheck.set.check.key " W " y 5 ] OK
catch { r aclcheck.set.check.key " W " v 5 } e
assert_match " * D E N I E D K E Y * " $e
assert_equal [ r aclcheck.set.check.key " R " z 5 ] OK
catch { r aclcheck.set.check.key " R " v 5 } e
assert_match " * D E N I E D K E Y * " $e
}
2021-09-23 01:52:56 -04:00
test { test module check acl for module user} {
# the module user has access to all keys
assert_equal [ r aclcheck.rm_call.check.cmd.module.user set y 5 ] OK
}
test { test module check acl for channel perm} {
# block all channels but ch1
r acl setuser default resetchannels & ch1
assert_equal [ r aclcheck.publish.check.channel ch1 msg] 0
catch { r aclcheck.publish.check.channel ch2 msg} e
set e
} { * DENIED CHANNEL* }
test { test module check acl in rm_call} {
2022-01-26 14:03:21 -05:00
# rm call check for key permission (x: READ + WRITE)
2021-09-23 01:52:56 -04:00
assert_equal [ r aclcheck.rm_call set x 5 ] OK
2022-01-26 14:03:21 -05:00
assert_equal [ r aclcheck.rm_call set x 6 get] 5
# rm call check for key permission (y: only WRITE)
assert_equal [ r aclcheck.rm_call set y 5 ] OK
assert_error { * NOPERM * } { r aclcheck.rm_call set y 5 get}
Add new RM_Call flags for script mode, no writes, and error replies. (#10372)
The PR extends RM_Call with 3 new capabilities using new flags that
are given to RM_Call as part of the `fmt` argument.
It aims to assist modules that are getting a list of commands to be
executed from the user (not hard coded as part of the module logic),
think of a module that implements a new scripting language...
* `S` - Run the command in a script mode, this means that it will raise an
error if a command which are not allowed inside a script (flaged with the
`deny-script` flag) is invoked (like SHUTDOWN). In addition, on script mode,
write commands are not allowed if there is not enough good replicas (as
configured with `min-replicas-to-write`) and/or a disk error happened.
* `W` - no writes mode, Redis will reject any command that is marked with `write`
flag. Again can be useful to modules that implement a new scripting language
and wants to prevent any write commands.
* `E` - Return errors as RedisModuleCallReply. Today the errors that happened
before the command was invoked (like unknown commands or acl error) return
a NULL reply and set errno. This might be missing important information about
the failure and it is also impossible to just pass the error to the user using
RM_ReplyWithCallReply. This new flag allows you to get a RedisModuleCallReply
object with the relevant error message and treat it as if it was an error that was
raised by the command invocation.
Tests were added to verify the new code paths.
In addition small refactoring was done to share some code between modules,
scripts, and `processCommand` function:
1. `getAclErrorMessage` was added to `acl.c` to unified to log message extraction
from the acl result
2. `checkGoodReplicasStatus` was added to `replication.c` to check the status of
good replicas. It is used on `scriptVerifyWriteCommandAllow`, `RM_Call`, and
`processCommand`.
3. `writeCommandsGetDiskErrorMessage` was added to `server.c` to get the error
message on persistence failure. Again it is used on `scriptVerifyWriteCommandAllow`,
`RM_Call`, and `processCommand`.
2022-03-22 08:13:28 -04:00
assert_error { ERR acl verification failed, can' t access at least one of the keys mentioned in the command arguments.} { r aclcheck.rm_call_with_errors set y 5 get}
2022-01-26 14:03:21 -05:00
# rm call check for key permission (z: only READ)
assert_error { * NOPERM * } { r aclcheck.rm_call set z 5 }
Add new RM_Call flags for script mode, no writes, and error replies. (#10372)
The PR extends RM_Call with 3 new capabilities using new flags that
are given to RM_Call as part of the `fmt` argument.
It aims to assist modules that are getting a list of commands to be
executed from the user (not hard coded as part of the module logic),
think of a module that implements a new scripting language...
* `S` - Run the command in a script mode, this means that it will raise an
error if a command which are not allowed inside a script (flaged with the
`deny-script` flag) is invoked (like SHUTDOWN). In addition, on script mode,
write commands are not allowed if there is not enough good replicas (as
configured with `min-replicas-to-write`) and/or a disk error happened.
* `W` - no writes mode, Redis will reject any command that is marked with `write`
flag. Again can be useful to modules that implement a new scripting language
and wants to prevent any write commands.
* `E` - Return errors as RedisModuleCallReply. Today the errors that happened
before the command was invoked (like unknown commands or acl error) return
a NULL reply and set errno. This might be missing important information about
the failure and it is also impossible to just pass the error to the user using
RM_ReplyWithCallReply. This new flag allows you to get a RedisModuleCallReply
object with the relevant error message and treat it as if it was an error that was
raised by the command invocation.
Tests were added to verify the new code paths.
In addition small refactoring was done to share some code between modules,
scripts, and `processCommand` function:
1. `getAclErrorMessage` was added to `acl.c` to unified to log message extraction
from the acl result
2. `checkGoodReplicasStatus` was added to `replication.c` to check the status of
good replicas. It is used on `scriptVerifyWriteCommandAllow`, `RM_Call`, and
`processCommand`.
3. `writeCommandsGetDiskErrorMessage` was added to `server.c` to get the error
message on persistence failure. Again it is used on `scriptVerifyWriteCommandAllow`,
`RM_Call`, and `processCommand`.
2022-03-22 08:13:28 -04:00
assert_error { ERR acl verification failed, can' t access at least one of the keys mentioned in the command arguments.} { r aclcheck.rm_call_with_errors set z 5 }
2022-01-26 14:03:21 -05:00
assert_error { * NOPERM * } { r aclcheck.rm_call set z 6 get}
Add new RM_Call flags for script mode, no writes, and error replies. (#10372)
The PR extends RM_Call with 3 new capabilities using new flags that
are given to RM_Call as part of the `fmt` argument.
It aims to assist modules that are getting a list of commands to be
executed from the user (not hard coded as part of the module logic),
think of a module that implements a new scripting language...
* `S` - Run the command in a script mode, this means that it will raise an
error if a command which are not allowed inside a script (flaged with the
`deny-script` flag) is invoked (like SHUTDOWN). In addition, on script mode,
write commands are not allowed if there is not enough good replicas (as
configured with `min-replicas-to-write`) and/or a disk error happened.
* `W` - no writes mode, Redis will reject any command that is marked with `write`
flag. Again can be useful to modules that implement a new scripting language
and wants to prevent any write commands.
* `E` - Return errors as RedisModuleCallReply. Today the errors that happened
before the command was invoked (like unknown commands or acl error) return
a NULL reply and set errno. This might be missing important information about
the failure and it is also impossible to just pass the error to the user using
RM_ReplyWithCallReply. This new flag allows you to get a RedisModuleCallReply
object with the relevant error message and treat it as if it was an error that was
raised by the command invocation.
Tests were added to verify the new code paths.
In addition small refactoring was done to share some code between modules,
scripts, and `processCommand` function:
1. `getAclErrorMessage` was added to `acl.c` to unified to log message extraction
from the acl result
2. `checkGoodReplicasStatus` was added to `replication.c` to check the status of
good replicas. It is used on `scriptVerifyWriteCommandAllow`, `RM_Call`, and
`processCommand`.
3. `writeCommandsGetDiskErrorMessage` was added to `server.c` to get the error
message on persistence failure. Again it is used on `scriptVerifyWriteCommandAllow`,
`RM_Call`, and `processCommand`.
2022-03-22 08:13:28 -04:00
assert_error { ERR acl verification failed, can' t access at least one of the keys mentioned in the command arguments.} { r aclcheck.rm_call_with_errors set z 6 get}
2021-09-23 01:52:56 -04:00
# verify that new log entry added
set entry [ lindex [ r ACL LOG] 0 ]
assert { [ dict get $entry username] eq { default } }
assert { [ dict get $entry context] eq { module } }
2022-01-26 14:03:21 -05:00
assert { [ dict get $entry object] eq { z } }
2022-04-12 01:16:17 -04:00
assert { [ dict get $entry reason] eq { key } }
2021-09-23 01:52:56 -04:00
# rm call check for command permission
r acl setuser default - set
catch { r aclcheck.rm_call set x 5 } e
assert_match { * NOPERM * } $e
Add new RM_Call flags for script mode, no writes, and error replies. (#10372)
The PR extends RM_Call with 3 new capabilities using new flags that
are given to RM_Call as part of the `fmt` argument.
It aims to assist modules that are getting a list of commands to be
executed from the user (not hard coded as part of the module logic),
think of a module that implements a new scripting language...
* `S` - Run the command in a script mode, this means that it will raise an
error if a command which are not allowed inside a script (flaged with the
`deny-script` flag) is invoked (like SHUTDOWN). In addition, on script mode,
write commands are not allowed if there is not enough good replicas (as
configured with `min-replicas-to-write`) and/or a disk error happened.
* `W` - no writes mode, Redis will reject any command that is marked with `write`
flag. Again can be useful to modules that implement a new scripting language
and wants to prevent any write commands.
* `E` - Return errors as RedisModuleCallReply. Today the errors that happened
before the command was invoked (like unknown commands or acl error) return
a NULL reply and set errno. This might be missing important information about
the failure and it is also impossible to just pass the error to the user using
RM_ReplyWithCallReply. This new flag allows you to get a RedisModuleCallReply
object with the relevant error message and treat it as if it was an error that was
raised by the command invocation.
Tests were added to verify the new code paths.
In addition small refactoring was done to share some code between modules,
scripts, and `processCommand` function:
1. `getAclErrorMessage` was added to `acl.c` to unified to log message extraction
from the acl result
2. `checkGoodReplicasStatus` was added to `replication.c` to check the status of
good replicas. It is used on `scriptVerifyWriteCommandAllow`, `RM_Call`, and
`processCommand`.
3. `writeCommandsGetDiskErrorMessage` was added to `server.c` to get the error
message on persistence failure. Again it is used on `scriptVerifyWriteCommandAllow`,
`RM_Call`, and `processCommand`.
2022-03-22 08:13:28 -04:00
catch { r aclcheck.rm_call_with_errors set x 5 } e
assert_match { ERR acl verification failed, can' t run this command or subcommand.} $e
2021-09-23 01:52:56 -04:00
# verify that new log entry added
set entry [ lindex [ r ACL LOG] 0 ]
assert { [ dict get $entry username] eq { default } }
assert { [ dict get $entry context] eq { module } }
assert { [ dict get $entry object] eq { set } }
2022-04-12 01:16:17 -04:00
assert { [ dict get $entry reason] eq { command } }
2021-09-23 01:52:56 -04:00
}
2022-01-23 03:05:06 -05:00
test " U n l o a d t h e m o d u l e - a c l c h e c k " {
assert_equal { OK } [ r module unload aclcheck]
}
2021-09-23 01:52:56 -04:00
}