![사용자 "shadows+"(shadowsocks?)는 어디에 정의되어 있나요?](https://linux55.com/image/199108/%EC%82%AC%EC%9A%A9%EC%9E%90%20%22shadows%2B%22(shadowsocks%3F)%EB%8A%94%20%EC%96%B4%EB%94%94%EC%97%90%20%EC%A0%95%EC%9D%98%EB%90%98%EC%96%B4%20%EC%9E%88%EB%82%98%EC%9A%94%3F.png)
ss-server
Ubuntu에서 (패키지의) 에이전트를 실행하고 있습니다 .shadowsocks-libev
나는 이것이 .as 사용자에 의해 다음과 같이 실행 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
암호를 알 수 있습니다.
따라서 모든 사용자가 구성 파일을 읽을 수 있다는 사실은 제 생각에는 (사소한?) 보안 취약점입니다.
/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와 일치하도록 합니다.