ทำไมแพ็คเกจลินุกซ์จึงคาดว่าจะได้รับอนุญาตให้ติดตั้ง

นี่เป็นคำถามเกี่ยวกับตัวเลือกการออกแบบของ * ระวังไม่ใช่วิธีหลีกเลี่ยง

มีจุดประสงค์ในการกำหนดสิทธิ์การเข้าถึงรูทเพื่อติดตั้งแพ็คเกจส่วนใหญ่อย่างไร ดูเหมือนว่าช่องโหว่ความปลอดภัยที่อาจเกิดขึ้นนั้นต้องการให้คุณใช้รูทเนื่องจากแพ็คเกจส่วนใหญ่ไม่จำเป็นต้องแก้ไขเคอร์เนลหรือต้องการสิทธิ์รูทในการรัน หากวัตถุประสงค์เพียงเพื่อติดตั้งแพคเกจหนึ่งครั้งต่อเครื่องเพื่อให้ผู้ใช้ทุกคนประหยัดพื้นที่ดังนั้นทำไมไม่มีผู้ใช้ที่ไม่ใช่รูทคนอื่นสำหรับวัตถุประสงค์นี้

อัปเดต: ฉันกำลังสันนิษฐานว่าที่นี่แพ็กเกจที่ติดตั้งโดยไม่มีการเข้าถึงรูทจะไม่ถูกติดตั้งใน dirs ที่ป้องกันโดย root แต่จะใช้ที่อื่นแทน

ดังที่คนอื่น ๆ ระบุไว้ในความคิดเห็นเหตุผลที่ชัดเจนสำหรับการขออนุญาตรูทคือแพ็คเกจที่สร้างไว้ล่วงหน้าจะติดตั้งไปยังไดเรกทอรีของระบบที่ใช้ร่วมกันซึ่งไม่ควรเขียนได้โดยใครก็ตาม ทำไมไม่ "ผู้ใช้ที่ไม่ใช่รูทคนอื่น" ฉันจะบอกว่าแพคเกจพอจำเป็นต้องทำการเปลี่ยนแปลงไฟล์ระบบและไดเรกทอรีที่ใช้ร่วมกันซึ่งไม่คุ้มค่ากับความซับซ้อนในการติดตามว่าแพ็คเกจใดที่จำเป็นต้องใช้รูทและไม่ต้องการและเพราะการติดตั้งแบบรูทไม่ได้ซื้อคุณทั้งหมด ขนาดนั้น - คุณได้แสดงความเชื่อมั่นให้กับผู้จำหน่ายแล้วสำหรับแพ็คเกจหลักจำนวนมากดังนั้นสิ่งที่เพิ่มเติมอีกเล็กน้อย แต่ท้ายที่สุดก็ใช่ว่าจะมีการแลกเปลี่ยนความปลอดภัยและดูเหมือนว่าผู้ขายได้ตัดสินใจว่าความเรียบง่ายชนะที่นี่

สิ่งนี้ทำให้เรามีคำถามว่าทำไมแพคเกจไม่สามารถติดตั้งได้เพียงแค่ไดเรกทอรีหลักของผู้ใช้ ที่จริงแล้วในหลาย ๆ กรณีสามารถทำได้ แต่เฉพาะในกรณีที่คุณใช้การกระจายแบบอิงแหล่งข้อมูลเช่น Gentoo ในกรณีนี้คุณเพียงแค่รวบรวมโปรแกรมด้วยความเหมาะสม --prefix หรือการโต้แย้งที่คล้ายกัน (ส่วนใหญ่ แต่ไม่ใช่ทั้งหมด) ชิ้นส่วนของซอฟต์แวร์ที่สนับสนุนแนวคิดดังกล่าว) Distros ส่วนใหญ่นั้นใช้ระบบเลขฐานสองและในกรณีนี้ปัญหาคือโปรแกรม Unix จำนวนมากถูกเขียนในลักษณะที่เส้นทางต่าง ๆ จะถูก hardcoded ลงในโปรแกรมในเวลาคอมไพล์และต้องทำงานและประสานงานเป็นจำนวนมาก เมื่อต้องการเปลี่ยนแปลงสิ่งนี้เมื่อคุณจัดการกับแพ็คเกจและผู้ดูแลหลายพันคน การประสานงานเป็นเรื่องยากโดยเฉพาะอย่างยิ่งในโลก Unix เนื่องจากมีผู้จำหน่ายระบบจำนวนมากซึ่งแตกต่างจาก Windows ซึ่ง Microsoft สามารถกำหนดการเปลี่ยนแปลงในระดับที่ดี - และแม้แต่ Microsoft มีปัญหาในการทำให้ทุกคนตกอยู่ในสาย การจำลองเสมือน UAC .

พิจารณาเพิ่มเติมเกี่ยวกับปัญหาเส้นทางฮาร์ดโค้ดพิจารณาโปรแกรม foo ที่ต้องการเข้าถึงฐานข้อมูลของบางประเภท ไฟล์นี้อยู่ที่ไหน เส้นทางที่เป็นไปได้คือ /usr/share/foo/foo.dbซึ่งจะถูก hardcoded ลงในโปรแกรมเพื่อให้รู้ได้อย่างแม่นยำว่าจะต้องมองตรงไหน คุณอาจโต้แย้งว่าโปรแกรมสามารถลองได้ $HOME/usr/share/foo/foo.db หรือคล้ายกันหากไม่พบไฟล์ฮาร์ดโค้ด นี่เป็นเรื่องจริงและน่าจะดียกเว้นว่าไม่มีมาตรฐานหรือแบบแผนที่แท้จริงสำหรับสิ่งเหล่านี้ดังนั้นโปรแกรมส่วนใหญ่จึงไม่ใช้กลไกทางเลือกดังกล่าว (ปัญหาการประสานงานนั้นอีกครั้ง) และยังเพิ่มความซับซ้อนที่เป็นประโยชน์ต่อผู้ใช้ส่วนน้อย แต่ก็เป็นเวิร์มตัวอื่น

ปัญหาที่เกี่ยวข้องคือวิธีที่โปรแกรมโหลดไลบรารีที่แบ่งใช้มันขึ้นอยู่กับ ตัวเชื่อมโยงแบบไดนามิก ld.soต้องการทราบว่าจะหาไลบรารีที่แชร์เหล่านี้ทั้งหมดได้ที่ไหน โดยทั่วไปรายการของเส้นทางสามารถ (อีกครั้ง) ฮาร์ดโค้ดลงในไฟล์เรียกทำงานที่รวบรวมเวลาซึ่งในกรณีนี้ ld.so จะค้นหาเส้นทางเหล่านี้ก่อน ความล้มเหลวนั้น ld.so ค้นหาไดเรกทอรีที่กำหนดค่าใน /etc/ld.so.conf. ปัญหานี้ค่อนข้างง่ายที่จะเอาชนะเช่นโดยการตั้งค่า LD_LIBRARY_PATH ตัวแปรสภาพแวดล้อมอย่างเหมาะสม

ดังนั้นสิ่งที่สำคัญที่สุดคือโปรแกรมจำนวนมากไม่ได้ถูกออกแบบมาให้มีความยืดหยุ่น (ในขณะรันไทม์) เกี่ยวกับวิธีการค้นหาไฟล์ของพวกเขาและจากนั้นผู้พัฒนาบรรจุภัณฑ์ไม่พบว่าคุ้มค่าที่จะเสนอตัวเลือกในการติดตั้งทางเลือก ไดเรกทอรี ไม่ใช่ว่าเป็นไปไม่ได้ในทางเทคนิค - จนถึงตอนนี้ยังไม่มีความตั้งใจที่จะสร้างมาตรฐานและทำให้ทุกคนติดตามมัน สำหรับตัวอย่างที่แสดงให้เห็นว่าเป็นไปไม่ได้ในทางเทคนิคคุณอาจลองดูคำตอบของฉันสำหรับคำถามนี้: ติดตั้ง git บนเซิร์ฟเวอร์โดยไม่ใช้ sudo . สังเกตว่ามันเป็นวิธีการแก้ปัญหาที่น่าเกลียดและนั่นคือสิ่งที่น่าเศร้า

สำหรับบันทึกนี้ฉันแบ่งปันความคับข้องใจของคุณในการไม่สามารถติดตั้งไบนารีแพคเกจได้อย่างง่ายดายไปยังที่ตั้งอื่นและฉันใช้เวลาและความพยายามเป็นเวลานานหลายปีในการรวบรวมแพ็คเกจด้วยตนเองหรือการแก้ไขปัญหาบรรจุภัณฑ์ คำถามที่ฉันเชื่อมโยงไปถึงในย่อหน้าก่อนหน้า) เมื่อทำงานบนระบบที่ sysadmins ไม่ร่วมมือกับการติดตั้งแพคเกจที่ฉันต้องการใช้