chroot 환경에 침입하기 위해 사용자 정의 스크립트를 사용하고 있습니다. (이것은 보안 감옥이 아닙니다. 제어된 설치된 패키지 및 도구 세트(호스트 환경과 다름)를 사용하여 다른 작업을 컴파일하고 수행할 수 있도록 존재합니다. - 호스트는 Ubuntu이고 chroot는 Debian입니다.
이 경우 스크립트는 상당히 표준적인 설치 세트로 간주되는 작업을 수행합니다.
mount -t proc "$ROOTPATH/proc"
mount -t sysfs "$ROOTPATH/sys"
mount --bind /dev "$ROOTPATH/dev"
mount --bind /dev/pts "$ROOTPATH/dev/pts"
하지만 chroot 내부에서 호스트 파일 시스템에 액세스하여 파일을 앞뒤로 복사할 수 있기를 원합니다(앞서 말했듯이 이것은 실제로 감옥은 아닙니다).
mount --rbind / "$ROOTPATH/host"
mount --make-rslave "$ROOTPATH/host"
(이 명령은 다음과 같습니다.이 답변.)
대부분의 경우 이는 예상대로 정확하게 작동합니다.
그러나 chroot 환경에 여러 번 들어가고 나가면(물론 종료하면 해당 umount가 실행됨) rbind위 호출이 결국 실패하고 다음이 표시됩니다.
mount(2) system call failed: No space left on device.
사용 가능한 디스크 공간(및 참조에 따르면 inode)이 많이 있으며 df -i, 물론 실제로 공간을 사용하는 것이 아니라 기존 파일 시스템을 바인딩해야 합니다.
물론 루트 파일 시스템은 물론 $ROOTPATH/host그 자체를 포함하고 있기 때문에(또는 실제로는 이 경우에는 일종의 - 실제로는 /mnt. 아래에 마운트된 다른 파일 시스템에 상주하기 때문에 이것은 약간의 재귀적 기이함을 포함합니다. 그러나 마운트된 파일 시스템 호스트가 표시되기를 원합니다. chroot에도 적용되므로 재귀 마운트를 사용합니다). 하지만 내가 말했듯이, 대부분의 경우 이것이 효과가 있습니다.
내 생각엔 이 질문이 그것과 관련이 있는 것 같아. 하지만 나는 $ROOTPATHchroot 내에서 포함된 파일 시스템에 액세스할 수 있기를 원합니다 . 나는 무한히 반복하지 않는 것이 충분히 똑똑하다고 생각합니다(그리고 $ROOTPATH/host/$ROOTPATH다른 마운트 지점이 아닌 비어 있음). 실제로 이것은 명령이 작동하는 경우입니다.
단일 명령을 사용하십시오.
mount --rbind --make-rslave / "$ROOTPATH/host"
시스템이 ENOSPC 상태인 경우에도 성공적으로 실행되지만 재귀 마운트가 아닌 단순 바인드 마운트만 수행합니다.
다르게 해야 할 일이 있나요? 아니면 오류를 "삭제"하고 다시 작동하게 만드는 방법이 있나요?
(시스템을 다시 시작하면 다시 작동하지만 매번 그렇게 하고 싶지는 않습니다.)