Why Should You Install Software as Root but Run It as a Non‑Root User?

On a server, any software such as toolkits, Redis, Nginx, etc., should be installed using the root account.

The correct approach is: install as root, run the process as a non‑root user.

Root installation writes executables to system environment paths, allowing all users to invoke them, while non‑root users are granted only the permissions needed to run the process.

Running a process as root is dangerous because any exploited command (e.g., rm -rf /) would execute with full system privileges.

Therefore, processes should never run as root; assign the necessary file and directory permissions to the non‑root user instead.

Typical installation steps for tar‑based packages (e.g., Redis, Nginx) follow the pattern make → compile source, then sudo make install → copy binaries to system locations; the source can be removed afterward.

System‑level configuration files are usually edited by root, but frequently modified files (e.g., Nginx conf) can be placed in a user directory with read/write permissions granted to that user.

Modify the permissions of files such as /etc/redis.conf to allow non‑root access, but be aware of the security implications.

Avoid granting excessive permissions to regular users, especially for system‑level configuration files.

Store configuration files in user directories instead of system directories when possible.

Use appropriate file permissions (e.g., read‑only) to limit access.

Employ security tools or configuration‑management solutions to ensure configuration file safety.

In production, prevent ordinary users from modifying system‑level configuration files and keep permissions as restrictive as possible.