用户"shadows+“在哪里？定义？

Question

我正在Ubuntu上运行ss-server代理(来自shadowsocks-libev包)。

我相信ss-server是由systemd管理的。ss-server以用户shadows+的身份运行，如下所示：

$  ps u -C ss-server
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
shadows+  719498  0.0  0.7  16244  7976 ?        Ss   Nov30   0:06 /usr/bin/ss-server -c /etc/shadowsocks-libev/config.json
$  ps un -C ss-server
    USER     PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
   64677  719498  0.0  0.7  16244  7976 ?        Ss   Nov30   0:06 /usr/bin/ss-server -c /etc/shadowsocks-libev/config.json

这个shadows+用户在哪里定义的？我没有在/etc/passwd中看到这个用户。

可能实际的用户名类似于shadowsocks，并且被截断为8个字符。但是即使如此，这个用户在/etc/passwd中并不存在。

所以问题仍然存在，这个用户是在哪里定义的？

更新：

对于telcoM的回答，我将提供更多的背景信息，解释为什么我对shadowsocks-libev用户感到好奇。

ss-server以用户64677的身份运行(至少目前如此)。

ss-server读取其配置文件/etc/shadowsocks-libev/config.json。

任何用户都可以读取此配置文件(默认情况下安装在Ubuntu上)。

此配置文件包含(默认情况下)一个半保密密码(该密码可能是在系统上安装包时生成的)。

理想情况下，只有ss-server程序和任何连接到ss-server的ss-client程序都知道这个密码。

因此，任何用户都可以读取配置文件的事实是，IMO (温和的？)安全漏洞。

我正在考虑更改/etc/shadowsocks-libev/config.json (或其父目录)的所有权。所以我想知道这个数字用户ID是否在重新启动时是稳定的。

<#>SECOND更新：

由于telcoM的答复和评论，我找到了以下文件：/etc/systemd/system/multi-user.target.wants/shadowsocks-libev.service

#  This file is part of shadowsocks-libev.
#
#  Shadowsocks-libev is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 3 of the License, or
#  (at your option) any later version.
#
#  This file is default for Debian packaging. See also
#  /etc/default/shadowsocks-libev for environment variables.

[Unit]
Description=Shadowsocks-libev Default Server Service
Documentation=man:shadowsocks-libev(8)
After=network-online.target

[Service]
Type=simple
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
DynamicUser=true
EnvironmentFile=/etc/default/shadowsocks-libev
LimitNOFILE=32768
ExecStart=/usr/bin/ss-server -c $CONFFILE $DAEMON_ARGS

[Install]
WantedBy=multi-user.target

注意，上面的文件包含DynamicUser=true。该文件缺少一个StateDirectory=条目。

Answer 1

首先，检查passwd:行中的/etc/nsswitch.conf。

你很可能会找到它，passwd: compat systemd说。如果是这样的话，那么您的系统除了使用经典的systemd-userdbd.service来查找用户信息外，还使用了/etc/passwd。这使得软件包可以轻松地添加和删除特定于应用程序的用户帐户，方法是将适当的JSON文件删除到/usr/lib/userdb/或/etc/userdb/ (或与容器等一起使用的/run/userdb )。

有关更多信息，请阅读系统上的man nss-systemd或按照这个链接。

查看getent passwd 64677所说的内容，通过UID号查找用户帐户，并以类似于/etc/passwd行的格式查看基本用户信息。这至少应该显示完整的用户名，然后你可以搜索它。例如，如果您发现用户名实际上是shadowsocks1，您可以运行：

grep -r shadowsocks1 /etc /usr /run

这可能会产生许多误击，但如果用户帐户具有持久的本地定义，则不管如何定义，都应该找到它。

systemd-userdbd.service还可以支持在服务启动时“创建”的动态用户，以及服务关闭时停止存在的动态用户。这些将永远不会存储在/etc/passwd或任何文件中。这一特性是在systemd 232版中添加的，在235版中有了显著的扩展。根据systemd文档，用于动态用户的UID范围为61184-65519。

欲了解更多信息：https://0pointer.net/blog/dynamic-users-with-systemd.html

检查运行ss-server的systemd服务的服务定义:如果它包含DynamicUser=yes，那么它将确认此功能正在使用。要确定UID是否持久，请查看服务定义是否包括StateDirectory=定义。如果定义了一个StateDirectory，那么只要/var/lib/private/目录没有被删除，并且服务的名称没有改变，UID号就应该是稳定的。

如果/etc/shadowsocks-libev/config.json的语法允许引用其他文件以便包含到配置中，则可以将配置的秘密部分放入StateDirectory和chowned的文件中；在这种情况下，即使动态UID必须更改，systemd也会自动将状态目录及其内容与新的UID相匹配。