- 21 Feb, 2019 7 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
antirez authored
-
Oran Agra authored
* bigkeys used to fail on databases with module type keys * new code adds more types when it discovers them, but has no way to know element count in modules types yet * bigkeys was missing XLEN command for streams * adding --memkeys and --memkeys-samples to make use of the MEMORY USAGE command see #5167, #5175
-
- 19 Feb, 2019 2 commits
- 18 Feb, 2019 2 commits
- 14 Feb, 2019 1 commit
-
-
antirez authored
Reltaed to discussion and PR #5840.
-
- 13 Feb, 2019 5 commits
-
-
Madelyn Olson authored
-
Madelyn Olson authored
-
zhaozhao.zz authored
Adding another new filed categories at the end of command reply, it's easy to read and distinguish flags and categories, also compatible with old format.
-
antirez authored
That's not REALLY needed, but... right now with LASTSAVE being the only command tagged as "admin" but not "dangerous" what happens is that after rewrites the rewrite engine will produce from the rules: user default on +@all ~* -@dangerous nopass The rewrite: user default on nopass ~* +@all -@admin -@dangerous +lastsave Which is correct but will have users wondering about why LASTSAVE has something special. Since LASTSAVE after all also leaks information about the underlying server configuration, that may not be great for SAAS vendors, let's tag it as dangerous as well and forget about this issue :-)
-
zhaozhao.zz authored
-
- 12 Feb, 2019 5 commits
-
-
antirez authored
-
antirez authored
-
zhaozhao.zz authored
In mostly production environment, normal user's behavior should be limited. Now in redis ACL mechanism we can do it like that: user default on +@all ~* -@dangerous nopass user admin on +@all ~* >someSeriousPassword Then the default normal user can not execute dangerous commands like FLUSHALL/KEYS. But some admin commands are in dangerous category too like PSYNC, and the configurations above will forbid replica from sync with master. Finally I think we could add a new configuration for replication, it is masteruser option, like this: masteruser admin masterauth someSeriousPassword Then replica will try AUTH admin someSeriousPassword and get privilege to execute PSYNC. If masteruser is NULL, replica would AUTH with only masterauth like before.
-
antirez authored
Related to #5832.
-
zhaozhao.zz authored
-
- 11 Feb, 2019 5 commits
-
-
Chris Lamb authored
__x86_64__ is defined on the on the x32 architecture and the conditionals in debug.c therefore assume the size of (void*) etc: debug.c: In function 'getMcontextEip': debug.c:757:12: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] return (void*) uc->uc_mcontext.gregs[16]; /* Linux 64 */ ^ debug.c: In function 'logRegisters': debug.c:920:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] logStackContent((void**)uc->uc_mcontext.gregs[15]); We can remedy this by checking for __ILP32__ first. See: https://wiki.debian.org/ArchitectureSpecificsMemo ... for more info.
-
antirez authored
Otherwise it's very simple for an human mistake to think a password is removed because of a typo in the ACL SETUSER myuser <somepass command line.
-
antirez authored
The part that is fixed is that now if the default user is off whatever is its configuration the user is not considered authenticated.
-
antirez authored
Soon or later we may have code in freeClient() that may have to deal with ACLs. Imagine for instance the command proposed multiple times (not sure if this will ever be accepted but still...): ONCLOSE DEL mykey Accumulating commands to run when a client is disconnected. Now the function is compatible with such use cases. Related to #5829.
-
zhaozhao.zz authored
-
- 08 Feb, 2019 3 commits
-
-
antirez authored
-
antirez authored
-
antirez authored
We can't trust modules commands flagging, so module commands must be always explicitly added, with the exception of +@all that will include everything. However something like +@readonly should not include command from modules that may be potentially dangerous: our categories must be safe and reliable and modules may not be like that.
-
- 07 Feb, 2019 9 commits
- 06 Feb, 2019 1 commit
-
-
antirez authored
-