1. 08 Apr, 2017 1 commit
  2. 30 Jan, 2017 1 commit
    • antirez's avatar
      Security: Cross Protocol Scripting protection. · 874804da
      antirez authored
      This is an attempt at mitigating problems due to cross protocol
      scripting, an attack targeting services using line oriented protocols
      like Redis that can accept HTTP requests as valid protocol, by
      discarding the invalid parts and accepting the payloads sent, for
      example, via a POST request.
      
      For this to be effective, when we detect POST and Host: and terminate
      the connection asynchronously, the networking code was modified in order
      to never process further input. It was later verified that in a
      pipelined request containing a POST command, the successive commands are
      not executed.
      874804da
  3. 12 Sep, 2016 2 commits
  4. 28 Jul, 2016 1 commit
    • antirez's avatar
      Ability of slave to announce arbitrary ip/port to master. · 0a45fbc3
      antirez authored
      This feature is useful, especially in deployments using Sentinel in
      order to setup Redis HA, where the slave is executed with NAT or port
      forwarding, so that the auto-detected port/ip addresses, as listed in
      the "INFO replication" output of the master, or as provided by the
      "ROLE" command, don't match the real addresses at which the slave is
      reachable for connections.
      0a45fbc3
  5. 27 Jul, 2016 1 commit
    • antirez's avatar
      Avoid simultaneous RDB and AOF child process. · 21cffc26
      antirez authored
      This patch, written in collaboration with Oran Agra (@oranagra) is a companion
      to 780a8b1d. Together the two patches should avoid that the AOF and RDB saving
      processes can be spawned at the same time. Previously conditions that
      could lead to two saving processes at the same time were:
      
      1. When AOF is enabled via CONFIG SET and an RDB saving process is
         already active.
      
      2. When the SYNC command decides to start an RDB saving process ASAP in
         order to serve a new slave that cannot partially resynchronize (but
         only if we have a disk target for replication, for diskless
         replication there is not such a problem).
      
      Condition "1" is not very severe but "2" can happen often and is
      definitely good at degrading Redis performances in an unexpected way.
      
      The two commits have the effect of always spawning RDB savings for
      replication in replicationCron() instead of attempting to start an RDB
      save synchronously. Moreover when a BGSAVE or AOF rewrite must be
      performed, they are instead just postponed using flags that will try to
      perform such operations ASAP.
      
      Finally the BGSAVE command was modified in order to accept a SCHEDULE
      option so that if an AOF rewrite is in progress, when this option is
      given, the command no longer returns an error, but instead schedules an
      RDB rewrite operation for when it will be possible to start it.
      21cffc26
  6. 04 Jul, 2016 2 commits
    • antirez's avatar
      In Redis RDB check: better error reporting. · 35b18bfb
      antirez authored
      35b18bfb
    • antirez's avatar
      In Redis RDB check: initial POC. · f578f085
      antirez authored
      So far we used an external program (later executed within Redis) and
      parser in order to check RDB files for correctness. This forces, at each
      RDB format update, to have two copies of the same format implementation
      that are hard to keep in sync. Morover the former RDB checker only
      checked the very high-level format of the file, without actually trying
      to load things in memory. Certain corruptions can only be handled by
      really loading key-value pairs.
      
      This first commit attempts to unify the Redis RDB loadig code with the
      task of checking the RDB file for correctness. More work is needed but
      it looks like a sounding direction so far.
      f578f085
  7. 15 Jun, 2016 1 commit
  8. 30 May, 2016 1 commit
    • Itamar Haber's avatar
      Allow SPOP from Lua scripts · 620783e3
      Itamar Haber authored
      The existing `R` flag appears to be sufficient and there's no apparent reason why the command should be blocked.
      620783e3
  9. 18 May, 2016 1 commit
  10. 05 May, 2016 6 commits
  11. 04 May, 2016 3 commits
  12. 02 May, 2016 2 commits
    • antirez's avatar
      Fix INFO commandstats reporting when argv is rewritten. · ba9154d7
      antirez authored
      We want to report the original command in the stats, for example GEOADD,
      even when what is actually executed is the ZADD implementation.
      ba9154d7
    • antirez's avatar
      BITFIELD command initial implementation. · 761a7728
      antirez authored
      The new bitfield command is an extension to the Redis bit operations,
      where not just single bit operations are performed, but the array of
      bits composing a string, can be addressed at random, not aligned
      offsets, with any width unsigned and signed integers like u8, s5, u10
      (up to 64 bit signed integers and 63 bit unsigned integers).
      
      The BITFIELD command supports subcommands that can SET, GET, or INCRBY
      those arbitrary bit counters, with multiple overflow semantics.
      
      Trivial and credits:
      
      A similar command was imagined a few times in the past, but for
      some reason looked a bit far fetched or not well specified.
      Finally the command was proposed again in a clear form by
      Yoav Steinberg from Redis Labs, that proposed a set of commands on
      arbitrary sized integers stored at bit offsets.
      
      Starting from this proposal I wrote an initial specification of a single
      command with sub-commands similar to what Yoav envisioned, using short
      names for types definitions, and adding control on the overflow.
      
      This commit is the resulting implementation.
      
      Examples:
      
          BITFIELD mykey OVERFLOW wrap INCRBY i2 10 -1 GET i2 10
      761a7728
  13. 18 Feb, 2016 1 commit
  14. 05 Feb, 2016 1 commit
  15. 26 Jan, 2016 1 commit
  16. 08 Jan, 2016 1 commit
    • antirez's avatar
      New security feature: Redis protected mode. · 273c49e7
      antirez authored
      An exposed Redis instance on the internet can be cause of serious
      issues. Since Redis, by default, binds to all the interfaces, it is easy
      to forget an instance without any protection layer, for error.
      
      Protected mode try to address this feature in a soft way, providing a
      layer of protection, but giving clues to Redis users about why the
      server is not accepting connections.
      
      When protected mode is enabeld (the default), and if there are no
      minumum hints about the fact the server is properly configured (no
      "bind" directive is used in order to restrict the server to certain
      interfaces, nor a password is set), clients connecting from external
      intefaces are refused with an error explaining what to do in order to
      fix the issue.
      
      Clients connecting from the IPv4 and IPv6 lookback interfaces are still
      accepted normally, similarly Unix domain socket connections are not
      restricted in any way.
      273c49e7
  17. 17 Dec, 2015 2 commits
    • antirez's avatar
      Fix a race that may lead to the active (slave) client to be freed. · 7a7e46b2
      antirez authored
      In issue #2948 a crash was reported in processCommand(). Later Oran Agra
      (@oranagra) traced the bug (in private chat) in the following sequence
      of events:
      
      1. Some maxmemory is set.
      2. The slave is the currently active client and is executing PING or
         REPLCONF or whatever a slave can send to its master.
      3. freeMemoryIfNeeded() is called since maxmemory is set.
      4. flushSlavesOutputBuffers() is called by freeMemoryIfNeeded().
      5. During slaves buffers flush, a write error could be encoutered in
         writeToClient() or sendReplyToClient() depending on the version of
         Redis. This will trigger freeClient() against the currently active
         client, so a segmentation fault will likely happen in
         processCommand() immediately after the call to freeMemoryIfNeeded().
      
      There are different possible fixes:
      
      1. Add flags to writeToClient() (recent versions code base) so that
         we can ignore the write errors, and use this flag in
         flushSlavesOutputBuffers(). However this is not simple to do in older
         versions of Redis.
      2. Use freeClientAsync() during write errors. This works but changes the
         current behavior of releasing clients ASAP when possible. Normally
         we write to clients during the normal event loop processing, in the
         writable client, where there is no active client, so no care must be
         taken.
      3. The fix of this commit: to detect that the current client is no
         longer valid. This fix is a bit "ad-hoc", but works across all the
         versions and has the advantage of not changing the remaining
         behavior. Only alters what happens during this race condition,
         hopefully.
      7a7e46b2
    • antirez's avatar
      Fix processCommand() comment about return value. · f50dfff0
      antirez authored
      f50dfff0
  18. 13 Dec, 2015 1 commit
  19. 27 Nov, 2015 1 commit
    • antirez's avatar
      Handle wait3() errors. · 1cc7a454
      antirez authored
      My guess was that wait3() with WNOHANG could never return -1 and an
      error. However issue #2897 may possibly indicate that this could happen
      under non clear conditions. While we try to understand this better,
      better to handle a return value of -1 explicitly, otherwise in the
      case a BGREWRITE is in progress but wait3() returns -1, the effect is to
      match the first branch of the if/else block since server.rdb_child_pid
      is -1, and call backgroundSaveDoneHandler() without a good reason, that
      will, in turn, crash the Redis server with an assertion.
      1cc7a454
  20. 19 Nov, 2015 3 commits
  21. 17 Nov, 2015 2 commits
    • antirez's avatar
      Remove "s" flag for MIGRATE in command table. · b96938b1
      antirez authored
      Maybe there are legitimate use cases for MIGRATE inside Lua scripts, at
      least for now. When the command will be executed in an asynchronous
      fashion (planned) it is possible we'll no longer be able to permit it
      from within Lua scripts.
      b96938b1
    • antirez's avatar
      Fix MIGRATE entry in command table. · 1236471b
      antirez authored
      Thanks to Oran Agra (@oranagra) for reporting. Key extraction would not
      work otherwise and it does not make sense to take wrong data in the
      command table.
      1236471b
  22. 10 Nov, 2015 1 commit
  23. 09 Nov, 2015 2 commits
  24. 05 Nov, 2015 1 commit
  25. 30 Oct, 2015 1 commit