使用者“shadows+”（shadowsocks？）在哪裡定義？
我在 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-client連接的程序ss-server會知道這個密碼。因此，任何使用者都可以讀取配置文件這一事實在 IMO 中是一個（輕微的？）安全漏洞。
我正在考慮更改
/etc/shadowsocks-libev/config.json（或其父目錄）的所有權。所以我想知道這個數字使用者 ID 是否會在重新啟動後保持穩定。第二次更新：
感謝電信公司的回答和評論，我找到了以下文件：
/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=條目。
首先，檢查
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 匹配。