Run Redis as an unprivileged user

The fix/etc/systemd/system/redis-server.service.d/user.conf

[Service]
User=redis
Group=redis
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/redis /var/log/redis /run/redis

sudo systemctl daemon-reload
sudo systemctl restart redis-server

Distribution packages already run as redis (or valkey). This page mostly matters for hand-rolled installs and containers.

Why it matters

Redis’s own documentation states plainly that it “does not require root privileges to run” and recommends an unprivileged redis user.

The reason is specific rather than general hygiene. Redis can be made to write files to arbitrary paths — CONFIG SET dir plus CONFIG SET dbfilename plus SAVE writes the dataset wherever you point it. That is the standard exploitation path for an exposed instance.

The user Redis runs as decides what that write can reach:

• As redis: the attacker writes files owned by redis, in places redis can write. Bad, and often enough to pivot — but bounded.
• As root: the same write lands in /root/.ssh/authorized_keys, or /etc/cron.d/, or a systemd unit. That is not a pivot, it is the machine.

Same bug, same command, entirely different blast radius. This control doesn’t stop the write; it decides what the write costs you.

The systemd hardening directives are the free part

User=redis is the essential line. The rest above are cheap additions that narrow the same write further:

Directive	Effect
NoNewPrivileges	The process cannot gain privileges via setuid
ProtectSystem=strict	The entire filesystem is read-only except ReadWritePaths
ProtectHome	/home, /root and /run/user are inaccessible
PrivateTmp	Private /tmp, so no tmp-based interference

ProtectSystem=strict with an explicit ReadWritePaths is the one that pays. It means even a successful CONFIG SET dir /etc/cron.d cannot write, because the path is read-only to the process regardless of file permissions.

Containers

USER redis in the Dockerfile, or user: redis in compose. Running Redis as root inside a container is common and is a smaller problem than on a host — but combined with a bind mount it reaches the host filesystem as root, which puts you straight back to the worst case.

Verify it worked

Check the actual running process, not the unit file:

ps -o user,group,args -C redis-server
# or:  ps -o user,group,args -C valkey-server

Expect redis, not root.

Confirm systemd’s view and the sandboxing:

systemctl show redis-server -p User -p NoNewPrivileges -p ProtectSystem

Then prove the sandbox actually holds — this should fail even though the path exists:

sudo -u redis touch /etc/cron.d/test

Expect permission denied. If that succeeds, ProtectSystem is not in effect and a file write is not contained.

Before you apply this

Low risk if you’re only adding the systemd directives to a package install that already runs as redis.

Two ways it bites:

ProtectSystem=strict breaks paths you forgot. If Redis writes anywhere not in ReadWritePaths — a custom dir, a logfile, a unix socket location — it fails at startup or on save. Check your config’s dir, logfile and unixsocket values and make sure each is covered.

Changing the user on an existing install orphans the data. Files in /var/lib/redis are owned by whoever wrote them. If Redis ran as root and you switch it to redis, it may not be able to read its own dump on restart:

sudo chown -R redis:redis /var/lib/redis /var/log/redis

Do that before restarting, or Redis starts with an empty dataset — which on a cache is a stampede, and on a persistence-backed store is worse.

Related

• Secure the config and data files — the permissions on what this user owns.
• Restrict dangerous commands with ACLs — removing CONFIG removes the write.