저는 많은 테스트/검증 작업 없이는 업그레이드할 수 없는 매우 오래된 glibc가 포함된 레거시 시스템을 가지고 있습니다.
이제 이 시스템에서 최신 프로그램(예: Java 1.7)을 여러 번 실행해야 합니다. 저는 필요한 모든 라이브러리를 패키지하고 chroot에서 서비스를 실행하는 chroot 솔루션을 선택했습니다.
그러나 chroot는 매우 제한적이므로 문제를 해결하려면 LD_LIBRARY_PATH를 사용하는 것이 좋습니다. 불행히도 libc.so.6: cannot handle TLS data이 작업을 시도하면 오류가 발생합니다.
/lib/ld-linux.so.2chroot에서도 그것이 필요하다는 것이 밝혀졌습니다 . 이것은 작동합니다:
LD_LIBRARY_PATH=/home/chroot/lib /home/chroot/lib/ld-linux.so.2 /home/chroot/bin/program
그러나 바이너리의 이름이 "bin/java"가 아닌 경우 라이브러리가 로드되는 위치를 java확인하여 이를 방지하는 방법은 실패합니다. /proc/self/cmdlinejava는 시작 중에도 자체적으로 실행되므로 상황이 더욱 복잡해집니다.
이 작업을 수행하기 위한 마지막 시도로 16진수 편집기를 사용하여 Java 바이너리를 열고 문자열을 다음 /lib/ld-linux.so.2으로 바꾸었고 /home/chroot/ld.so(심볼릭 링크로 만들었음 ld-linux.so.2) 작동했습니다!
그러나 각각의 새로운 바이너리의 경로를 중첩 시스템의 절대 경로로 다시 작성하는 것이 매우 번거롭다는 점에는 모두가 동의할 것이라고 생각합니다.
사용자 정의 라이브러리 경로를 사용하는 더 명확한 방법을 아는 사람이 있습니까?포함하다ld-linux.so를 사용자 정의하시겠습니까?
답변1
16진수 편집기를 사용하여 발견한 것처럼 로더의 경로는 바이너리로 컴파일됩니다. 실제로 /lib/ld-linux.so.2와 /home/chroot/ld.so길이가 같기 때문에 운이 좋게도 바이너리 파일을 직접 편집할 수 있습니다. 이러한 문자열의 길이는 이진 파일에도 있으므로 문자열을 직접 수정하면 미묘한 문제가 발생할 수 있습니다.
이 경로를 선택하게 된다면 다음과 같은 사항을 살펴봐야 합니다.파헬프통역사를 업데이트하세요. 이를 통해 통역사를 빠르고 안전하게 영구적으로 변경할 수 있습니다.