☰

用户“shadows+”（shadowsocks？）在哪里定义？

tag-icon • tag-icon systemd users shadowsocks
用户“shadows+”（shadowsocks？）在哪里定义？

我正在Ubuntu 上运行ss-server代理（从包中）。shadowsocks-libev

我相信ss-server是由systemd. ss-server以 user 身份运行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-client连接到的任何程序ss-server才会知道该密码。

因此，任何用户都可以读取配置文件这一事实在我看来是一个（轻微的？）安全漏洞。

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

第二次更新：

感谢 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=条目。

答案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

检查正在运行的 systemd 服务的服务定义ss-server：如果它包含DynamicUser=yes，则确认此功能正在使用。要查明 UID 是否持久，请查看服务定义是否包含StateDirectory=定义。如果定义了StateDirectory，只要目录/var/lib/private/<StateDirectory value>不被删除并且服务名称不被改变，UID号就应该是稳定的。

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

相关内容