systemd DynamicUser 기준

systemd 서비스에서 전용 시스템 계정을 둘지 고민된다면 DynamicUser=를 먼저 검토할 수 있습니다. 이 설정은 서비스가 시작될 때 임시 UNIX 사용자와 그룹을 할당하고, 서비스가 멈추면 다시 반환하는 방식입니다.

결론부터 말하면, 파일을 남기지 않거나 systemd가 관리하는 전용 디렉터리에만 상태를 저장하는 장기 실행 서비스에는 DynamicUser=yes가 잘 맞습니다. 반대로 고정 UID가 필요하거나, 외부 권한 정책과 사용자 이름을 강하게 묶어야 하거나, 서비스가 임의의 경로에 파일을 계속 남겨야 한다면 정적 사용자 계정이 더 명확합니다.

DynamicUser는 무엇을 바꿀까

DynamicUser=는 systemd.exec에 정의된 실행 환경 설정입니다. 이 값을 켜면 서비스 시작 시점에 사용자와 그룹 쌍이 동적으로 할당되고, 서비스가 종료되면 해제됩니다. 이 계정은 일반적인 방식으로 /etc/passwd나 /etc/group에 추가되는 계정이 아니라 런타임 동안 관리되는 계정입니다.

User=나 Group=을 함께 지정하면 그 이름으로 동적 계정을 만들 수 있습니다. 지정하지 않으면 systemd가 unit 이름에서 사용자 이름을 유도합니다. 단, 같은 이름의 정적 사용자나 그룹이 이미 있으면 동적 할당 대신 기존 계정을 사용합니다.

[Service]
DynamicUser=yes
ExecStart=/usr/local/bin/example-daemon

중요한 점은 UID와 GID가 재사용될 수 있다는 사실입니다. 공식 문서 기준으로 동적 사용자는 정해진 범위에서 할당되며, 어떤 unit이 종료된 뒤 같은 숫자 UID가 다른 unit에 다시 배정될 수 있습니다. 따라서 동적 사용자가 소유한 파일을 아무 위치에나 남기는 설계는 피해야 합니다.

왜 쓰기 경로를 함께 설계해야 할까

DynamicUser=yes는 사용자만 임시로 만드는 옵션이 아닙니다. 이 옵션이 켜지면 NoNewPrivileges=, RestrictSUIDSGID=, ProtectSystem=strict, ProtectHome=read-only 같은 제한이 함께 적용됩니다. 서비스가 임의의 시스템 경로에 쓰지 못하도록 막는 방향입니다.

그래서 상태 파일이 필요한 서비스라면 ReadWritePaths=로 넓게 예외를 여는 것보다, 목적에 맞는 systemd 디렉터리 설정을 먼저 쓰는 편이 안전합니다.

설정	주요 위치	적합한 데이터
RuntimeDirectory=	/run/	PID 파일, UNIX socket, 실행 중에만 필요한 임시 상태
StateDirectory=	/var/lib/	서비스 재시작 뒤에도 유지되어야 하는 상태
CacheDirectory=	/var/cache/	삭제되어도 다시 만들 수 있는 캐시
LogsDirectory=	/var/log/	서비스 전용 로그 파일
ConfigurationDirectory=	/etc/	서비스 전용 설정 파일

공식 문서 기준으로 StateDirectory=, CacheDirectory=, LogsDirectory=는 DynamicUser=와 함께 쓸 때 UID 재사용 문제를 줄이도록 별도의 보호 경로를 사용합니다. 서비스 내부에서는 보통 /var/lib/이름처럼 보이지만, 호스트 쪽에서는 접근이 제한된 private 경로와 심볼릭 링크가 사용될 수 있습니다.

간단한 서비스 파일은 어떻게 생길까

아래 예시는 전용 상태 디렉터리와 런타임 디렉터리를 systemd에 맡기는 형태입니다. 실행 파일 자체의 옵션은 서비스마다 다르지만, 계정과 쓰기 경로를 unit 파일에서 함께 선언한다는 점이 핵심입니다.

[Unit]
Description=Example service with a dynamic user

[Service]
DynamicUser=yes
ExecStart=/usr/local/bin/example-daemon
RuntimeDirectory=example
StateDirectory=example
CacheDirectory=example

이 경우 서비스는 실행 중 필요한 파일을 $RUNTIME_DIRECTORY, 오래 유지할 상태를 $STATE_DIRECTORY, 다시 만들 수 있는 캐시를 $CACHE_DIRECTORY 아래에 두도록 작성하는 편이 좋습니다. systemd는 해당 디렉터리를 만들고, 필요한 환경 변수도 설정합니다.

언제 DynamicUser가 잘 맞을까

선택 기준은 파일 소유권, 외부 연동, 권한 모델입니다. 단순히 “보안에 좋아 보인다”는 이유만으로 켜면 서비스가 기존 경로에 쓰지 못해 실패할 수 있습니다. 반대로 쓰기 경로를 명확히 관리할 수 있는 서비스라면 운영자가 별도 시스템 계정을 만들고 회수하는 부담을 줄일 수 있습니다.

상황	판단	이유
전용 데몬이 제한된 상태 파일만 필요함	DynamicUser=yes 검토	계정 생명주기와 쓰기 경로를 unit에 묶을 수 있음
서비스가 임의의 기존 디렉터리에 파일을 남김	구조 변경 우선	UID 재사용 시 남은 파일 소유권이 문제가 될 수 있음
고정 UID가 백업, ACL, 컨테이너, 네트워크 파일시스템과 연결됨	정적 사용자 선호	외부 시스템이 숫자 UID나 이름을 안정적으로 기대할 수 있음
D-Bus 서비스 이름을 직접 소유해야 함	문서 확인 필요	공식 문서는 현재 이 옵션과 D-Bus policy의 호환성 제한을 언급함

ReadWritePaths로 풀면 충분할까

ReadWritePaths=는 ProtectSystem=strict 환경에서 특정 경로를 쓰기 가능하게 여는 설정입니다. 하지만 DynamicUser=와 함께 쓸 때는 조심해야 합니다. systemd가 관리하지 않는 경로에 동적 UID 소유 파일이 남으면, 나중에 같은 UID를 받은 다른 서비스가 그 파일에 접근할 수 있는 조건이 생길 수 있습니다.

따라서 기본 순서는 RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=를 먼저 검토하고, 그래도 필요한 경우에만 좁은 범위로 ReadWritePaths=를 추가하는 것입니다. 이때도 서비스가 파일을 어디에 만들고, 종료 후 무엇을 남기는지 확인해야 합니다.

정적 사용자와 어떻게 다를까

정적 사용자는 배포나 부팅 과정에서 미리 만들어 두는 계정입니다. 패키지형 서비스, 다른 프로세스와 권한을 공유해야 하는 서비스, 운영 정책상 UID를 고정해야 하는 서비스에는 정적 사용자가 더 예측 가능합니다. systemd 환경에서는 sysusers.d 같은 방식으로 시스템 사용자를 만들 수 있습니다.

DynamicUser=는 그 반대편에 있습니다. 서비스가 독립적이고, 파일 경로가 unit에 잘 선언되어 있으며, 계정 자체를 사람이 직접 관리할 필요가 적을 때 유용합니다. 특히 네트워크에 노출되는 작은 데몬처럼 권한을 좁히고 싶은 경우에는 좋은 출발점이 될 수 있습니다.

자주 묻는 질문

DynamicUser를 쓰면 User를 쓰지 않아도 될까

가능합니다. User=를 지정하지 않으면 unit 이름에서 동적 사용자 이름이 유도됩니다. 다만 로그나 운영 문서에서 이름을 명확히 남기고 싶다면 User=를 함께 지정하는 방식도 검토할 수 있습니다.

서비스가 종료되면 파일도 모두 지워질까

아닙니다. RuntimeDirectory=로 만든 런타임 디렉터리는 기본적으로 서비스 정지 시 제거됩니다. 그러나 StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory=로 만든 디렉터리는 서비스 정지 후에도 남습니다. 종류별 수명을 구분해서 써야 합니다.

DynamicUser만 켜면 서비스가 완전히 격리될까

아닙니다. 이 옵션은 사용자 계정과 여러 기본 제한을 함께 다루지만, 네트워크, system call, device, capability 같은 모든 격리를 대신하지는 않습니다. 서비스 성격에 따라 CapabilityBoundingSet=, PrivateDevices=, SystemCallFilter= 같은 다른 제한을 별도로 검토합니다.

정리

DynamicUser=의 핵심은 계정을 임시로 만든다는 점보다, 그 임시 계정이 남길 수 있는 파일과 권한을 어떻게 관리하느냐입니다. 파일을 남기지 않는 서비스라면 단순하게 적용할 수 있고, 상태가 필요한 서비스라면 systemd의 전용 디렉터리 설정과 함께 쓰는 것이 기준입니다.

운영 기준은 세 가지입니다. 첫째, 서비스가 필요한 쓰기 경로를 모두 파악합니다. 둘째, 가능한 경로는 RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=로 선언합니다. 셋째, 고정 UID나 외부 권한 정책이 필요한 서비스라면 정적 사용자를 선택합니다. 이 기준을 잡고 적용하면 DynamicUser=를 단순한 옵션이 아니라 서비스 권한 설계의 일부로 쓸 수 있습니다.