大多数时候，从源安装程序时，建议创建一个新用户和一个新组，并授予/usr/local/<myapp>最近创建的用户和组所有权。
为什么这种做法被视为良好做法？
它有什么改善？
示例：MySQL 数据库服务器的 mysql 用户/mysql 组。
答案1
实践不是为每个应用程序创建一个用户和组，而是为每个服务创建一个用户和组。也就是说，本地用户执行的程序不需要以 root 以外的用户身份安装。它是守护进程，在后台运行并执行通过网络或其他通信方式发出的请求的程序，这些程序应作为专用用户运行。
该守护进程作为专用用户运行，因此如果它行为不当（由于错误，可能是由攻击者触发），它所能造成的损害是有限的：只有守护进程的数据文件受到影响（除非攻击者设法找到本地根漏洞） ，这可能发生）。例如，数据库守护程序mysqld作为专用用户和组运行mysql:mysql，数据库 ( /var/lib/mysql/*) 的数据文件属于mysql:mysql。
请注意，守护程序可执行文件以及守护程序使用但不应修改的其他静态数据和配置文件不得属于专用用户；root:root像大多数程序和配置文件一样，它们应该属于。该mysqld进程没有业务覆盖/usr/sbin/mysqld或/etc/mysql/my.cnf，因此这些文件不能属于该mysql用户或不能被该mysql用户或mysql组写入。如果某些文件需要仅由守护程序和管理员读取，则它们应由用户 root 和专用组拥有，并且模式为 0640 ( rw-r-----)。
一类不能被用户拥有的特殊可执行文件root:root是由用户调用但需要以额外权限运行的程序。这些可执行文件必须是设定值root 如果他们需要（至少部分）以 root 身份运行；那么可执行文件必须具有模式 4755 ( rwsr-xr-x)。如果程序需要额外的权限但不是 root，那么应该将程序设置为 setgid，以便额外的权限通过组而不是通过用户。可执行文件的模式为 2755 ( rwxr-sr-x)。原因有两个：
- 不应允许可执行文件修改自身，因此，如果用户设法利用漏洞，他们可能能够修改程序使用的数据文件，但不能注入特洛伊木马进入可执行文件以攻击运行该程序的其他用户。
- 可执行文件的数据文件属于该组。setuid 程序必须在真实用户（调用程序的用户）与用户交互和有效用户（程序以之运行的用户）之间切换，以访问其私有数据文件（这是它拥有额外权限的原因）。setgid 程序还可以隔离仅组可访问的每个用户数据（例如，通过将用户拥有的文件存储在仅 root 和程序组可访问的目录中）。
答案2
它不是一般的应用程序，而是守护进程。原因是守护进程可以作为非特权用户而不是 root 运行，这样，如果它存在安全漏洞并受到损害，则可能造成的损害仅限于用户有权访问的区域。
答案3
它被认为是良好实践的原因是防止系统的其他用户覆盖特定应用程序的数据和配置文件。
例如mysql，mysql作为 mysql 数据库文件存储的所有者，可以防止任何不使用应用程序 API 的人损坏数据库。另外，用户mysql通常没有真正的 shell，因此也没有人可以以该用户身份登录。
答案4
这是出于安全考虑。它限制了闯入守护程序应用程序的人可能造成的损害。用户应用程序通常由标准用户 ID（例如 ）拥有root。
如果您的 Web 服务器、邮件服务器和数据库都以同一用户身份运行，那么它们就更容易受到攻击。如果其中任何一个存在允许系统访问的错误或配置错误，则该访问权限可用于访问所有三个应用程序。
如果按照建议，他们都有单独的帐户，则只有受感染的应用程序可能可以访问。虽然可以读取对方的公共配置详细信息，但不太可能进行更改。
许多守护进程允许用户上传和下载文件，或者执行您不希望他们对其他守护进程的配置执行的操作。如果每个应用程序都有自己的用户 ID 和组，那么保护守护程序的安全就更简单。
拥有守护程序特定组可以更轻松地安全地授予守护程序对文件和目录的安全只读访问权限。如果文件或目录属于其他用户，但属于守护程序组，则通常可以只读方式访问。可以使用 find 等工具轻松验证和更正访问权限。