사용자 "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가 재부팅 후에도 안정적으로 유지되는지 궁금합니다.

두 번째 업데이트:

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 번호로 사용자 계정을 조회하고, 한 줄 같은 형식으로 기본적인 사용자 정보를 확인해보세요 /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와 일치하도록 합니다.

관련 정보