Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
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.
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:
/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.)
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.
/usr/bin/at is owned by daemon/daemon on Ubuntu
at isn't a daemon. It's setuid daemon so that it can communicate with the atd daemon through private files.
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.
