Why is it recommended to create a group and user for some applications?

Question

Most of the time, when installing a program from source it is recommended to create a new user and a new group and give /usr/local/<myapp> the recently created user and group ownership.

• Why is such pratice considered as a good practice?

• What does it improve?

Example: mysql user/mysql group for the MySQL database server.

Solution 1

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 mysql:mysql.

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 /usr/sbin/mysqld or /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 (rw-r-----).

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).

Solution 2

It is not applications in general, but daemons that this is for. The reason is so that the daemon can run as an unprivileged user instead of root so that if it has a security vulnerability and is compromised, the damage that can be done is contained to only the areas that user has access to.

Solution 3

The reason it's considered a good practice is to prevent other users of the system overriding data and configuration files for the particular application.

As an example mysql/mysql being the owner of the storage for mysql database files prevents anyone not using the application API from corrupting the databases. Plus the user mysql usually doesn't have a real shell so noone can login as that user either.

Comments

[Gilles 'SO- stop being evil']

You missed a critical point, which is that it's what user and group the application is running on that matters, and the executable and other static files should be owned by root.

[Gilles 'SO- stop being evil']

You missed a critical point, which is that it's what user and group the application is running on that matters, and the executable and other static files should be owned by root.

[BillThor]

@Gilles: Noted and editted accordingly.

[Karlson]

@Gilles They can be owned by root and most applications installed via distributions are but they don't need to be and they don't have to be. As a matter of fact /usr/bin/at is owned by daemon/daemon on Ubuntu

[Gilles 'SO- stop being evil']

at isn't a daemon. It's setuid daemon so that it can communicate with the atd daemon through private files.