Description

After some time (~5 min, some event I guess), redis resets dir parameter to /etc.

To reproduce

  1. Initialize AWS EC2 instance as shown below:
        redis_conf_path = '/etc/redis/redis.conf'
        ec2_inst.user_data.add_commands(
            "yum check-update -y",
            "yum upgrade -y",
            "amazon-linux-extras install -y redis6",
            f"echo \"bind {ip} 127.0.0.1 ::1\" >> {redis_conf_path}",
            f"echo \"appendonly yes\" >> {redis_conf_path}",
            f"echo \"appendfsync always\" >> {redis_conf_path}",
            f"echo \"cluster-enabled yes\" >> {redis_conf_path}",
            f"echo \"cluster-config-file cluster.conf\" >> {redis_conf_path}",
            f"echo \"cluster-node-timeout 5000\" >> {redis_conf_path}",
            #f"echo \"loglevel warning\" >> {redis_conf_path}",
            f"echo \"dir /var/lib/redis\" >> {redis_conf_path}",
            "sysctl net.core.somaxconn=1024",
            "sysctl vm.overcommit_memory=1",
            "service redis restart",
        )
  1. Check everything looks as expected:
[ec2-user@ip-10-0-0-100 ~]$ redis-cli config get dir
1) "dir"
2) "/var/lib/redis"

[ec2-user@ip-10-0-0-100 ~]$ sudo ls -la /var/lib/redis
total 8
drwxr-x---  2 redis redis   48 Sep 16 15:28 .
drwxr-xr-x 31 root  root  4096 Sep 16 15:28 ..
-rw-r--r--  1 redis redis    0 Sep 16 15:28 appendonly.aof
-rw-r--r--  1 redis redis  114 Sep 16 15:28 cluster.conf

Expected behavior

dir should stay /var/lib/redis no matter what

Actual behavior

After some amount of time (~5 min) of doing nothing dir flips to /etc:

[ec2-user@ip-10-0-0-100 ~]$ redis-cli config get dir
1) "dir"
2) "/etc"

Causing "Permission denied" in logs:

/var/log/redis/redis.log
7069:C 16 Sep 2021 15:28:13.692 * Supervised by systemd. Please make sure you set appropriate values for TimeoutStartSec and TimeoutStopSec in your service unit.
7069:C 16 Sep 2021 15:28:13.692 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7069:C 16 Sep 2021 15:28:13.692 # Redis version=6.2.5, bits=64, commit=00000000, modified=0, pid=7069, just started
7069:C 16 Sep 2021 15:28:13.692 # Configuration loaded
7069:M 16 Sep 2021 15:28:13.692 * monotonic clock: POSIX clock_gettime
7069:M 16 Sep 2021 15:28:13.692 * No cluster configuration found, I'm cc772b7f69cfe8fac81985047e5dca3b8b6f5634
7069:M 16 Sep 2021 15:28:13.694 * Running mode=cluster, port=6379.
7069:M 16 Sep 2021 15:28:13.694 # Server initialized
7069:M 16 Sep 2021 15:28:13.694 * Ready to accept connections
7069:M 16 Sep 2021 15:33:12.595 * DB saved on disk
7069:M 16 Sep 2021 15:33:13.071 * DB saved on disk
7069:M 16 Sep 2021 15:33:15.273 * DB saved on disk
7069:M 16 Sep 2021 15:33:15.740 * DB saved on disk
7069:M 16 Sep 2021 15:33:15.973 * DB saved on disk
7069:M 16 Sep 2021 15:33:17.609 # Failed opening the RDB file zzh (in server root dir /etc/cron.d) for saving: Permission denied
7069:M 16 Sep 2021 15:33:18.309 # Failed opening the RDB file crontab (in server root dir /etc) for saving: Permission denied

Additional information

cat /etc/system-release
Amazon Linux release 2 (Karoo)

redis-server --version
Redis server v=6.2.5 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=84fcfe5c74097c6d

Comment From: oranagra

@rayrapetyan you're being attacked, probably don't have a password on your redis. someone's trying to use redis in order to hack to your system. i'd assume the instance is compromised and wipe it.