创建没有home的用户的正确方法(针对shadow.service)

创建没有home的用户的正确方法(针对shadow.service)

如果您使用在 Arch Linux 上创建一个没有主目录的用户useradd -M test,则会在 中创建如下所示的条目/etc/passwd

test:x:1001:1001::/home/test:/bin/bash

但因为/home/test不存在,这会导致shadow.service失败。将主目录留空会产生相同的错误。我发现一个旧线程建议使用/dev/null,但我不确定这是否是最好的解决方案。 ATM,忽略它似乎是最好的解决方案,但也许还有更好的方法。


shadow.service归结为pwckgrpck

### [...]
ExecStart=/bin/sh -c '/usr/bin/pwck -r || r=1; /usr/bin/grpck -r && exit $r
### [...]

答案1

基于 Debian

如果您使用的是基于 Debian 的系统,新的 - 默认情况下已经存在于多个基于 Debian 的发行版中(并且已经包含在下一个软件包版本的源代码中pwcklogin.defsshadow-utils以正确的方式解释不存在的情况主目录与/nonexistent路径一起。

如果您确实获得了最新的shadow-utils软件包,它将允许您配置/etc/login.defs并添加(或取消注释)以下选项:

这是来自man 8 pwck最新提交的新内容:

   NONEXISTENT (string)
      If a system account intentionally does not have a home directory
      that exists, this string can be provided in the /etc/passwd entry
      for the account to indicate this. The result is that pwck will
      not emit a spurious warning for this account.

实际的选项属于/etc/login.defs这样

# The [string] can be whatever word/path you want to use in your /etc/passwd file to
# correspond to a nonexistent directory. However, /nonexistent should be used as the default 
# nonexisting home directory, as that is already in use in many distributions. 

NONEXISTENT [string]

专门添加此选项是为了pwck考虑不存在的主目录,这是检查使用 中提供的配置shadow.service的有效性和完整性的底层命令。/etc/passwd/etc/login.defs

如果您确实使用此配置选项,则使用sudo adduser -M -d /nonexistent [username]后跟pwck -r不会引发错误。


其他发行版

虽然许多基于 Debian 的发行版已经针对这种特殊情况使用了这种方法,但还有其他变体使用自己的系统来处理不存在的主目录。

但是,您通常可以通过执行来测试您的发行版如何确定不存在的主目录情况

sudo grep nobody /etc/passwd

因为这个特定的非特权用户默认情况下永远不会有自己的主目录路径,但是在您的文件中找到的相应值/etc/passwd将为您提供系统如何处理它的线索。

例如:

  • RHEL/CentOS 使用 的/主目录作为故障保护,但nobody通过以下方式禁用其登录 shell/sbin/nologin

  • 基于 Debian 的发行版当前/nonexistent用于主目录和/usr/sbin/nologinshell

  • SUSE Linux,至少到 2019 年中期,用于 /var/lib/nobody目录和/bin/bashshell,但一些安全意识备忘录建议更改为/var/lib/nobody/bin/false

  • OSx 已使用且可能仍会 使用/var/empty/usr/bin/falsenobody

  • 我遇到过其他使用/nonexistent但允许使用 shell 的发行版/bin/sh


using 的问题sudo useradd [username]在于,它特别允许系统预设选项/etc/login.defs在执行时被覆盖,即使它们可能违反/etc/passwd.

我已经有一段时间没有测试了useradd,但是 - 除非对源代码进行了重大更改 --d选项标志的验证器有很多限制。当然存在一个检查,检查optarg[0]所提供的路径是否确实/以及路径是否包含:但我使用 运行的每个测试,因此如果实际执行时没有错误,* 我不会感到惊讶。sudo useradd -d /home/my:base [username]

相关内容