The practice is not to create one user and group per application, but per service. That is, programs that are executed by a local user don't need to be installed as a user other than root. It's daemons, programs running in the background and that execute requests coming through the network or other communication means, that should run as a dedicated user.
The daemon runs as a dedicated user so that if it misbehaves (due to a bug, probably triggered by an attacker) the damage it can do is limited: only the daemon's data files are affected (unless the attacker managed to find a local root hole, which can happen). For example, the database daemon
mysqld runs as a dedicated user and group
mysql:mysql and the data files of the database (
/var/lib/mysql/*) belong to
Note that the daemon executable and other static data and configuration files that are used but should not be modified by the daemon must not belong to the dedicated user; they should be owned by
root:root, like most program and configuration files. The
mysqld process has no business overwriting
/etc/mysql/my.cnf, so these files must not belong to the
mysql user or be writable by the
mysql user or the
mysql group. If some files need to be readable only by the daemon and the administrator, they should be owned by the user root and by the dedicated group, and have mode 0640 (
A special category of executables that cannot by owned by
root:root is programs that are invoked by a user but need to run with extra privileges. These executables must be setuid root if they need to run (at least in part) as root; then the executable must have mode 4755 (
rwsr-xr-x). If the program needs with extra privileges but not as root, then the program should be made setgid, so that the extra privileges come through a group and not through a user. The executable then has mode 2755 (
rwxr-sr-x). The reasons are twofold:
- The executable should not be allowed to modify itself, so that if a user manages to exploit a vulnerability, they might be able to modify the data files used by the program but not inject a trojan horse into the executable to attack other users running the program.
- The executable's data file belong to the group. A setuid program would have to switch between the real user (the user who invoked the program) to interact with the user and with the effective user (the user that the program is running as) to access its private data files (the reason for it to have extra privileges). A setgid program can furthermore segregate per-user data that are only accessible to the group (e.g. by storing files owned by the user in a directory that's only accessible to root and the program's group).