Secure the Redis config and data files

The fix

sudo chown root:redis /etc/redis/redis.conf
sudo chmod 640 /etc/redis/redis.conf

sudo chown -R redis:redis /var/lib/redis
sudo chmod 750 /var/lib/redis
sudo chmod 640 /var/lib/redis/dump.rdb 2>/dev/null || true

Substitute /etc/valkey/valkey.conf, /var/lib/valkey and the valkey user if that’s what you’re running.

Why it matters

Redis’s documentation notes that the password is “set by the system administrator in clear text inside the redis.conf file”. That is a reasonable design — but it means the file’s permissions are part of your authentication.

Two consequences that are easy to miss:

The config file is a credential. A 644 redis.conf means every local user — every service account, every deployment agent, anything that gets a shell through an unrelated bug — can read the password and authenticate as default. All the work in requiring authentication is undone by a chmod nobody looked at.

The dump file is the entire dataset. dump.rdb is your whole keyspace on disk, unencrypted. Reading it requires no password and no Redis connection at all — just filesystem access. Sessions, tokens, cached PII: all of it, readable.

640 with group redis gives the daemon what it needs and nothing to anyone else.

Don’t forget the ACL file

If you moved users out to an aclfile, that file now holds the secrets instead:

/etc/redis/redis.conf

aclfile /etc/redis/users.acl

sudo chown root:redis /etc/redis/users.acl
sudo chmod 640 /etc/redis/users.acl

An aclfile is worth using — ACL SAVE persists runtime user changes to it without rewriting your whole config — but it inherits exactly the same exposure as redis.conf, and it’s newer, so it’s more often missed.

Backups leak what the live files don’t

The permissions above protect the running host. They say nothing about the copy of dump.rdb in your backup bucket, which is the same unencrypted keyspace with a different access-control system in front of it — often a much weaker one.

If the dataset is sensitive enough to justify 640, it’s sensitive enough that the backups need encryption at rest and a look at who can read the bucket.

Verify it worked

Check what you have now:

ls -l /etc/redis/redis.conf /etc/redis/users.acl 2>/dev/null
ls -ld /var/lib/redis
ls -l /var/lib/redis/*.rdb 2>/dev/null

Expect -rw-r----- and no world bit anywhere.

Then prove it, rather than reading the mode — as an unprivileged user:

sudo -u nobody cat /etc/redis/redis.conf

Expect permission denied. If that prints your config, the password is readable by every account on the box.

Find any world-readable Redis file in one pass:

sudo find /etc/redis /var/lib/redis -perm -o=r -type f 2>/dev/null

Expect no output.

Before you apply this

Getting the ownership wrong stops Redis from starting, and the failure is a permission error in the journal rather than anything obvious.

The rule: the file must stay readable by the user Redis runs as. root:redis with 640 works because Redis is in the redis group. root:root with 640 does not — Redis cannot read its own config and refuses to start.

Check before you restart:

sudo -u redis test -r /etc/redis/redis.conf && echo readable || echo BROKEN

For /var/lib/redis, Redis needs write access to the directory, not just the file — it writes a temporary dump and renames it. 750 owned by redis:redis is correct; chmod 640 on the directory would break saves silently until the next restart.

Related

• Require authentication with ACL users — the secret this protects.
• Run Redis as an unprivileged user — who owns these files.