루트 감옥 드라이브의 마운트 해제 지연

루트 감옥 드라이브의 마운트 해제 지연

원래 시스템에 일부 소프트웨어를 설치하기 위해 rpm 및 yum(centos 7.5)이 포함된 루트 감옥을 만들었습니다.

작업 과정

  • sys, proc, dev를 루트 감옥에 마운트합니다.
  • 원래 시스템의 루트 "/"를 감옥에 마운트합니다. 실제로 기본 시스템에 소프트웨어를 설치하기 위해 루트 감옥을 사용하기 때문에 이는 중요합니다.
  • 일부 소프트웨어를 설치하는 데 필요한 mount /proc /rootJail/originalRoot/proc와 같이 rootJail에 있는 원래 시스템의 루트 디렉터리에 원래 시스템의 sys, proc 및 dev를 마운트합니다.
  • 루트 감옥에 들어가 소프트웨어를 설치하고 루트 감옥에서 나가세요
  • 루트 감옥에서 sys, proc, dev 제거
  • 루트 감옥의 원래 시스템에서 sys, proc, dev를 제거합니다.
  • 루트 감옥에서 원래 시스템 루트를 제거합니다. (여기서 실패합니다.)

umount: /rootJail/originalRoot: 대상이 사용 중입니다. (어떤 경우에는 장치를 사용하는 프로세스에 대한 유용한 정보를 lsof(8) 또는 fusionr(1)에서 찾을 수 있습니다)

따라서 기본적으로 원래 시스템 자체의 루트를 제외한 모든 것을 제거할 수 있습니다. 필수 루트 감옥을 제거하려면 이 작업을 수행해야 합니다.

문제는 루트 감옥 내부에 소프트웨어를 설치한 후 많은 프로세스가 시작된다는 것입니다. 그렇기 때문에 대상이 바쁘다고 말하는 것입니다. 이러한 프로세스를 모두 종료하면 시스템도 종료되므로 불가능합니다. 설치 경로가 정확하더라도 이러한 프로세스는 실제 시스템이 아닌 rootJail에 바인딩된 것처럼 보입니다. 또한 재부팅한 후에는 모든 것이 잘 작동합니다. (최악의 경우: 여기에서 폴더를 삭제하세요.)

나는 대부분 작동하는 게으른 제거를 시도했습니다. rootJail을 제거할 수 있으며 설치된 원래 시스템에는 해를 끼치지 않는 것 같습니다.

내 질문은: 이것이 안전한가요? 아니면 폴더를 마운트 해제하는 다른 솔루션이 있습니까?

답변1

따라서 이러한 프로세스가 무한정 계속 실행되기를 원하는 것 같습니다. 즉, 중첩된 chroot 환경에서 시작된 서비스 프로세스입니다. 이는 systemd가 아닌 셸에서 서비스 프로세스를 생성하고 있음을 나타냅니다.

일반적으로 이것은 나쁘기 때문에 피하는 것이 좋습니다.

CentOS 7은 systemdPID 1을 사용하여 시스템 서비스를 실행하고 관리하는 데 사용됩니다. 분명히 메인 시스템의 PID 1이 chroot에서 실행되고 있지 않습니다. 일반적으로 시스템 서비스 프로세스 시작을 요청하면 PID 1에서 분기되어깨끗한환경( .service관련 유닛 파일에 따라 사용자 정의). (여기에는 레거시 sysvinit 스크립트가 포함됩니다. 자동으로 생성된 파일로 가져옵니다 .service.)

chroot(이를 더 설명하자면 기술적으로 소켓에서 바인드 마운트를 실행하여 systemd와 통신하고 chroot 내에서 명령을 사용하여 호스트 시스템의 서비스를 작동하는 것이 가능합니다 .)

문제는 귀하의 접근 방식이 systemd의 장점을 잃는 것만이 아닙니다. 이는 시스템 서비스(데몬에 있는 경우)를 혼동하고 있음을 의미합니다. 예를 들어, 서비스가 시작되지 않은 것처럼 보일 수 있습니다( service foo status). 나중에 시도하면 service foo restart... systemd는 중지할 데몬이 있다는 것을 모르고 시작하려고 시도합니다.두번째대신 데몬 프로세스의 인스턴스입니다. 이는 디버깅에 약간 혼란스럽습니다! 일반적으로 TCP 포트 80을 수신하는 다른 프로그램이 이미 있기 때문에 웹 서버를 시작할 수 없다는 오류가 즉시 표시되지만, 다른 경우에는 두 개의 다른 데몬 인스턴스가 나타날 수 있습니다. 알아차리는 데 시간이 더 오래 걸리는 오류가 발생합니다.

관련 정보