Answers:
这种做法不是为每个应用程序创建一个用户和组，而是为每个服务创建一个用户和组。也就是说，由本地用户执行的程序不需要以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身份运行，则它们必须是setuid root。那么该可执行文件必须具有4755（rwsr-xr-x）模式。如果程序需要额外的特权但不是root用户，则应将其设置为setgid，以便额外的特权通过组而不是通过用户。可执行文件的模式为2755（rwxr-sr-x）。原因有两个：
之所以认为这是一种好的做法，是为了防止系统的其他用户覆盖特定应用程序的数据和配置文件。
作为一个例子mysql/ mysql被存储的不使用应用程序API从破坏数据库MySQL数据库文件可以防止任何人的所有者。另外，用户mysql通常没有真正的外壳，因此也没有人可以该用户身份登录。
/usr/bin/at归daemon/daemonUbuntu 所有
at不是守护进程。它是setuid，daemon以便它可以atd通过专用文件与守护程序通信。
为新安装的守护程序创建新的组/用户可以提高安全性。当服务器进程在这样的用户下运行时，它仅限于该用户的访问权限。相比之下：以root身份运行时，它可以执行所有操作。
万一您的守护程序配置错误和/或包含与安全相关的错误，此区别非常重要。
我不确定您对问题的第二部分的意思，即关于/usr/local所有权的部分。通常，X出于安全原因，运行守护程序的同一用户也拥有带有二进制文件的目录（因为在这种情况下，如果被利用，则可以更改它们）。但是应该通过以下方式访问带有守护程序工作的数据文件的目录X-配置此X目录的最简单方法是使数据目录/文件的所有者。
在自己的特殊用户下运行守护程序只是一种安全技术，其他守护程序包括某种“ chrooting”或使用强制访问控制（MAC）系统（例如SELinux）。
这是出于安全考虑。它限制了闯入守护程序应用程序的人可能造成的损坏。用户应用程序通常由标准用户ID拥有root。
如果您的Web服务器，邮件服务器和数据库都以同一用户身份运行，则可以更轻松地破坏它们。如果它们中的任何一个有错误或配置错误都允许系统访问，则可以使用该访问来访问所有三个应用程序。
如果它们都具有建议的单独帐户，则仅可能访问受感染的应用程序。尽管可以读取其他设备的公共配置详细信息，但不太可能进行更改。
许多守护程序允许用户上载和下载文件，否则会执行您不希望他们能够对其他守护程序进行的配置。如果每个应用程序都有自己的用户ID和组，则可以更轻松地保护守护程序。
具有特定于守护程序的组可以更轻松地安全地授予守护程序对文件和目录的只读安全访问权限。如果文件或目录由其他用户拥有，但属于守护程序组，则通常可以只读访问。使用诸如find之类的工具可以轻松地验证和纠正访问权限。