ユーザー "shadows+" (shadowsocks?) はどこで定義されていますか?

ユーザー "shadows+" (shadowsocks?) はどこで定義されていますか?

ss-serverUbuntuで(パッケージ内の)エージェントを実行しています。shadowsocks-libev

私はこれが.asユーザーによって次のように実行さss-serverれると思います。systemdss-servershadows+

$  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

実際のユーザー名は次のとおりで、shadowsocks8 文字に切り捨てられます。しかし、それにもかかわらず、ユーザーは/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が再起動後も安定しているかどうか疑問に思います。

2番目のアップデート:

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伝統的な方法を使用しています。これにより、パッケージは適切なJSONファイルまたはコンテナなど/etc/passwdにドラッグアンドドロップして、アプリケーション固有のユーザーアカウントを簡単に追加および削除できます。/usr/lib/userdb//etc/userdb//run/userdb

詳しくはman nss-systemdシステムをご覧ください。このリンクをクリックしてください

getent passwd 64677上記の内容を見て、UID番号でユーザーアカウントを検索し、1行同じ形式で基本的なユーザー情報を確認してください/etc/passwd。少なくとも完全なユーザー名が表示され、後で検索できます。たとえば、ユーザー名が実際であることがわかったら、shadowsocks1次のように実行できます。

grep -r shadowsocks1 /etc /usr /run

これにより、多くの誤ったルックアップが発生する可能性がありますが、ユーザーアカウントに継続的なローカル定義がある場合は、定義方法に関係なくそれを見つける必要があります。

systemd-userdbd.serviceまた、サポートすることができます動的ユーザーサービスの開始時に「生成」され、サービスが終了すると、もはや存在しません。これは/etc/passwdどのファイルにも保存されません。この機能は systemd バージョン 232 に追加され、バージョン 235 で大幅に拡張されました。システム文書によると、動的ユーザーに使用される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のファイルに入れて適切に編集できます。この場合、動的UIDが状態ディレクトリをchown変更する必要がある場合でも、systemdは自動的に調整されます。chownそしてその内容が新しいUIDと一致するようにします。

関連情報