问systemd DynamicUser与User

EN

DynamicUser更安全，因为它意味着：

• ProtectSystem=strict：除了API文件系统子树/dev/、/proc/和/sys/之外，整个文件系统层次结构都是只读的。
• ProtectHome=read-only：目录/home/、/root和/run/user是为该单元调用的进程创建的只读目录。
• PrivateTmp=yes：为执行的进程设置一个新的文件系统命名空间，并在其中挂载私有的/tmp/和/var/tmp/目录，这些目录不是由名称空间之外的进程共享的。这对于保护对进程临时文件的访问非常有用，但使得进程之间无法通过/tmp/或/var/tmp/共享。如果启用了此功能，则服务在这些目录中创建的所有临时文件将在服务停止后被删除。
• RemoveIPC=yes：用户和组拥有的所有System和POSIX对象--这个单元的进程在停止时被移除。

您可以通过在使用User=时显式地设置这些设置来模拟这些设置，从而有效地获得相同的保护。

DynamicUser=更好的一种方法是在创建服务实例时。假设您有foo.socket，它使用Accept=yes。在这种情况下，每次有人连接到您的套接字时，都会产生一个新的foo@%i.service。有了DynamicUser=，每个实例都有自己的名称空间和/tmp目录，如果使用User=，就会共享它们。

没有什么可以阻止您指定一个User选项，即使您设置了DynamicUser=true。

根据文档 for User= (重点雷)：

当与DynamicUser=一起使用时，指定的用户/组名称将在服务启动时动态分配，并在服务停止时释放--除非已经静态地分配了它(请参见下面)。如果不使用DynamicUser=，则指定的用户和组必须在服务启动时在用户数据库中静态创建，例如使用sysusers.d(5)工具，该工具在启动或包安装时应用。如果用户不存在，那么程序调用将失败。

但是，在DynamicUser=的文档部分中有一个限制：

...Note表示，如果指定了User=，并且具有名称的静态组存在，则需要具有名称的静态用户已经存在。类似地，如果指定了Group=，并且存在具有名称的静态用户，则需要具有名称的静态组已经存在。

基本上，这意味着，如果您使用User选项指定了一个自定义DynamicUser，并且存在一个与用户同名的组，那么用户本身肯定已经在系统上创建了。这同样适用于指定自定义Group。

例如。如果您指定了User=docker，并且您的系统上存在docker组，那么docker用户也必须已经存在，以便您使用该名称。

上述限制的解决方案基本上是确保您没有使用系统上已经存在的用户或组。

tl；

博士

要回答您的问题，DymamicUser=确实会提高安全性，但这不是使用User还是DynamicUser的问题。DynamicUser可以具有与其关联的实际User，但不会将该用户添加到/etc/passwd或/etc/group中。

来源：

• https://www.freedesktop.org/software/systemd/man/systemd.exec.html
• https://0pointer.net/blog/dynamic-users-with-systemd.html