2017-12-18 16 views
2

Alpine Linux 3.7 호스트에서 dockerd 17.10.0-ce을 사용하여 발생하는 이상한 문제를 추적하고 있습니다. 이 호스트의 모든 컨테이너에 대해 보이지만 Docker 이미지의 진입 점/명령으로 시작된 프로세스 트리는 컨테이너 자체 내에서 볼 수 없습니다. 비교해 보면 우분투 호스트에서 동일한 이미지는 프로세스 트리가 PID 1로 표시됩니다.Alpine Linux 3.7의 Docker 컨테이너 : 이상한 pid 1이 컨테이너의 pid 네임 스페이스에 표시되지 않습니다.

다음은 예제입니다.

% docker top testcontainer 
PID     USER    TIME    COMMAND 
6729    root    0:00    /bin/sh -c sleep 1000000 
6750    root    0:00    sleep 1000000 
이제

, 그 컨테이너 내부 쉘을 시작하고 프로세스를 확인 :

% docker run -d --name testcontainer --rm busybox /bin/sh -c 'sleep 1000000' 

는 프로세스가 제대로 dockerd으로 볼 수 있습니다 확인

명시 적으로 알려진 엔트리 포인트/명령을 사용하여 컨테이너를 실행 목록 :

% docker exec -t -i testcontainer /bin/sh 
/# ps -ef 
PID USER  TIME COMMAND 
    6 root  0:00 /bin/sh 
    12 root  0:00 ps -ef 

우리의 진입 점 명령 (/ bin/sh -c) 'sleep 1000000')이 컨테이너 내부에서 보이지 않습니다. 심지어 top을 실행해도 동일한 결과가 나타납니다.

여기에 누락 된 것이 있습니까? 동일한 도커 엔진 버전을 사용하는 Ubuntu 호스트에서 결과는 예상대로입니다. 이것은 컨테이너 PID 공간이 어떻게 분리되어 있는지에 대한 문제를 일으키는 Alpine의 강화 된 커널과 관련 될 수 있습니까?

조사 할 부분에 대한 도움을 주시면 감사하겠습니다.

답변

2

-b

이 문제가 grsecurity 모듈 알파인 커널 구현에 관련되어 보인다. 이 특정한 경우, GRKERNSEC_CHROOT_FINDTASK 커널 설정은 chroot 환경 외부에서 수행 할 수있는 프로세스를 제한하는 데 사용됩니다. 이것은 kernel.grsecurity.chroot_findtask sysctl 변수에 의해 제어됩니다.

kernel.grsecurity.chroot_findtask

여기에 Y를 말한다면, chroot로 내부 프로세스 은 fcntl을 가진 신호를 보내 죽일 수 없습니다,의 ptrace, capget 다음 grsecurity 문서에서

, getpgid, setpgid, getsid 또는 chroot 외부의 프로세스를 봅니다. sysctl 옵션이 인 경우, "chroot_findtask"라는 이름의 sysctl 옵션이 작성됩니다.

지금 내가 발견 한 유일한 해결 방법은 비 grsecurity 커널과 동일한 동작을 얻기 위해이 플래그뿐만 아니라 chroot_deny_mknodchroot_deny_chmod 플래그를 사용하지 않도록하는 것입니다.

kernel.grsecurity.chroot_deny_mknod=0 
kernel.grsecurity.chroot_deny_chmod=0 
kernel.grsecurity.chroot_findtask=0 

물론 이것은 시스템의 보안 기능을 우회하여 비활성화하지만 개발 환경에서 유효한 해결 방법 일 수 있기 때문에 이상적이지 않습니다.