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.

5 Answers 5


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).
  • "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." Why would these executables not be able to be owned by root:root? Commented Jul 19, 2022 at 19:20
  • @KevinWheeler Because setuid/setgid is based on ownership. If a program must run as user Alice no matter who invoked it, the executable file must be owned by Alice. (A way to avoid that is to run the executable via a different privilege elevation mechanism such as sudo.) Commented Jul 20, 2022 at 7:20
  • Right, so if a command needs to run as root, no matter who invoked it, then it must be owned by root (and have the appropriate setuid/setgid bit enabled), right? Commented Jul 21, 2022 at 2:58
  • @KevinWheeler Yes, for example /usr/bin/sudo itself must be owned by root and have the setuid bit set. (Some Linux distributions use capabilities instead, but that's not the case we're discussing in this thread.) Commented Jul 21, 2022 at 8:06

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.


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.

  • 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. Commented Jan 15, 2012 at 0:26
  • @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
    – Karlson
    Commented Jan 15, 2012 at 3:42
  • 1
    at isn't a daemon. It's setuid daemon so that it can communicate with the atd daemon through private files. Commented Jan 15, 2012 at 16:52

Creating a new group/user for a new installed daemon improves security. When the server process is run under such a user it is restricted to the access rights of that user. In comparison: when it is run as root it can do everything.

This difference is important in case your daemon is mis-configured and/or contains a security related bug.

I am not sure what you mean with the second part of your question, i.e. the part about /usr/local ownership. In general it does not make sense that the same user X under which a daemon runs for security reasons also owns the directory with the binaries (because in that case it could change them in case of a exploit). But the directory with data files the daemon works on should be accessible by X - the easiest way to configure this is to make X the owner of the data directories/files.

Running a daemon under its own special user is just one security technique, others include some sort of 'chrooting' or using mandatory access control (MAC) system (e.g. SELinux).


This is a security consideration. It limits the damage that can be done by someone who breaks into a daemon application. User application are usually owned by a standard userid such as root.

If your web server, mail server, and database all run as the same user it makes it easier to compromise them. If any one of them has a bug or misconfiguration that allow system access, that access can be used to access all three applications.

If they all have separate accounts, as recommended, only the compromised application is likely to be accessible. While public configuration details of the other may be read, it is unlikely that changes can be made.

Many daemons allow users to upload and download files and otherwise do things that your would not want them to be able to do to the configurations for other daemons. If each application has its own userid and group it is simpler to secure the daemons.

Having a daemon specific group makes it simpler to securely grant a daemon secure access read-only to files and directories. If the file or directory is owned by a different user, but belongs to the daemons group it will usually be accessible read-only. Access permissions can be easily verified and corrected with tools such as find.

  • 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. Commented Jan 15, 2012 at 0:26
  • @Gilles: Noted and editted accordingly.
    – BillThor
    Commented Jan 15, 2012 at 0:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .