흥미로운 사용 사례가 있습니다. 테스트용 가상 머신을 시뮬레이션하기 위해 컨테이너에서 systemd를 실행하고 있습니다. systemd를 잘 실행할 수 있지만 루트가 되기 위해 sudo를 수행하기 전에 컨테이너에서 수행되는 모든 작업이 올바른 사용자를 얻을 수 있도록 기본 사용자가 루트가 아닌 다른 사용자여야 합니다.
내 ENTRYPOINT것은 sudo /usr/lib/systemd/systemd --system --unit=multi-user.target그것이 대부분의 일에 효과가 있다는 것입니다. 그러나 sudosystemd는 호출로 인해 PID 1을 얻지 못하며 일부 다운스트림 systemd 장치는 PID 1에 의존합니다.
문서에 따르면:
프로세스 모델
sudo는 명령을 실행할 때 fork(2)를 호출하고 위에서 설명한 대로 실행 환경을 설정한 다음 하위 프로세스에서 execve 시스템 호출을 호출합니다. 기본 sudo 프로세스는 명령이 완료될 때까지 기다린 다음 명령의 종료 상태를 보안 정책의 닫기 기능에 전달하고 종료합니다. I/O 로깅 플러그인이 구성되거나 보안 정책에서 이를 명시적으로 요청하는 경우 새 의사 터미널("pty")이 생성되고 두 번째 sudo 프로세스를 사용하여 사용자의 기존 pty와 새 pty 제어 간에 작업을 전달합니다. 신호 pty가 명령을 실행 중입니다. 이 추가 프로세스를 통해 명령을 일시 중지하고 재개할 수 있습니다. 이것이 없으면 명령은 POSIX 용어로 "고아 프로세스 그룹"에 속하게 되며 작업 제어 신호를 수신하지 못하게 됩니다. 특별한 경우로, 정책 플러그인이 닫기 기능을 정의하지 않고 pty가 필요하지 않은 경우 sudo는 먼저 fork(2)를 호출하지 않고 명령을 직접 실행합니다. sudoers 정책 플러그인은 I/O 로깅이 활성화되거나, pty가 필요하거나, pam_session 또는 pam_setcred 옵션이 활성화된 경우에만 종료 기능을 정의합니다. PAM을 사용하는 시스템에서는 pam_session 및 pam_setcred가 기본적으로 활성화되어 있습니다.
Bash 와 마찬가지로 sudo가 실행 중인 하위 프로세스로 자신을 바꾸도록 지시하는 방법이 있나요 exec? 다른 더 좋은 방법이 있나요? 이 명령에 대해 "정책 플러그인"을 변경해야 할 것 같지만 어떻게 해야 할지 모르겠습니다.
답변1
이 문제를 해결했습니다.에스컬레이터라는 작은 Rust 애플리케이션. 실행 가능한 비트를 사용하여 suid루트로 실행한 다음 실제로 루트가 되어 전달된 내용을 실행하기 setuid전에 자신을 하위 프로세스로 대체합니다.setgid
답변2
명령줄을 제어할 수 있는 경우 ENTRYPOINT 명령에서 사용하는 대신 옵션(예: ) docker run을 전달하는 것을 고려할 수 있습니다 .--user--user=0:0sudo
이 경우 ENTRYPOINT를 로 설정하여 /usr/lib/systemd/systemd --system --unit=multi-user.targetsystemd를 PID 1로 실행하면서 USER 설정을 그대로 유지하여 명령에 적용 할 수 있습니다 docker exec.
바라보다사용자에게 도달docker run참조 매뉴얼 에 있습니다 .
반대로 명령줄을 제어할 수 없는 경우 컨테이너 정의에서 USER를 루트로 남겨두고 명령을 docker run전달해 볼 수 있습니다 . 여기에는 해당 옵션을 모든 호출에 전달해야 하고 이를 전달할 user:group(또는 uid:gid)을 찾아야 하는 등 몇 가지 단점이 있습니다(루트는 간단하며 항상 0:0입니다.)--userdocker exec