1
การใช้ libc สำรองกับ ld-linux.so hacks; วิธีทำความสะอาด?
ฉันมีระบบดั้งเดิมที่มี glibc ที่เก่ามากซึ่งเราไม่สามารถอัพเกรดได้โดยไม่ต้องมีการทดสอบ / ตรวจสอบความถูกต้อง ฉันจำเป็นต้องเรียกใช้โปรแกรมใหม่ (เช่น Java 1.7) บนระบบนั้นหลายครั้งแล้ว ฉันเลือกโซลูชัน chroot ที่ฉันจัดเก็บ libs ที่จำเป็นทั้งหมดและเรียกใช้บริการใน chroot แม้ว่า chroot จะมีข้อ จำกัด มากและฉันอยากจะลองแก้ปัญหาด้วย LD_LIBRARY_PATH น่าเสียดายที่ฉันได้รับข้อผิดพลาดlibc.so.6: cannot handle TLS dataเมื่อฉันลองทำ ปรากฎว่าฉันต้องการ/lib/ld-linux.so.2จาก chroot เช่นกัน งานนี้: LD_LIBRARY_PATH=/home/chroot/lib /home/chroot/lib/ld-linux.so.2 /home/chroot/bin/program อย่างไรก็ตามjavaเกียดเคล็ดลับของฉันโดยการตรวจสอบ/proc/self/cmdlineเพื่อกำหนดที่จะโหลดห้องสมุดจากซึ่งล้มเหลวหากไบนารีไม่ได้ชื่อว่า 'bin / java' นอกจากนี้ java เรียกใช้ตัวเองในระหว่างการเริ่มต้นปัญหาที่ซับซ้อนมากขึ้น ในความพยายามครั้งสุดท้ายที่จะทำให้งานนี้ฉันเปิดไบนารี Java ด้วยโปรแกรมแก้ไขฐานสิบหกและแทนที่สตริง/lib/ld-linux.so.2ด้วย/home/chroot/ld.so(และทำให้ symlink เป็นld-linux.so.2) และทำงานได้! แต่ฉันคิดว่าทุกคนจะเห็นด้วยว่ามันเป็นกระบองขนาดใหญ่ที่จะเขียนเส้นทางของไบนารีใหม่ทุกตัวไปยังเส้นทางที่แน่นอนของระบบซ้อน ไม่มีใครรู้วิธีที่สะอาดกว่าการใช้เส้นทางไลบรารีที่กำหนดเองรวมถึง ld-linux.so …