มีเหตุผลว่าทำไมสิทธิ์ 'เจ้าของ' อยู่? สิทธิ์กลุ่มไม่เพียงพอหรือไม่

ฉันคิดว่าฉันค่อนข้างเข้าใจว่าการอนุญาตใช้ไฟล์ใน Linux เป็นอย่างไร อย่างไรก็ตามฉันไม่เข้าใจว่าทำไมพวกเขาจึงถูกแบ่งออกเป็นสามระดับและไม่เป็นสองระดับ

ฉันต้องการตอบปัญหาต่อไปนี้:

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

คำตอบสำหรับคนแรกควรอ้างอิงทั้งตำราหรือกระดานสนทนาอย่างเป็นทางการ

ใช้กรณีที่ฉันได้พิจารณาคือ:

• ไฟล์ส่วนตัว - หาได้ง่ายมากโดยการจัดกลุ่มต่อผู้ใช้บางสิ่งที่มักจะทำเหมือนในหลาย ๆ ระบบ
• การอนุญาตให้เจ้าของเท่านั้น (เช่นบริการระบบ) เขียนไฟล์อนุญาตเฉพาะกลุ่มบางกลุ่มที่จะอ่านและปฏิเสธการเข้าถึงอื่น ๆ ทั้งหมด - ปัญหาของตัวอย่างนี้คือเมื่อต้องการให้กลุ่มมีสิทธิ์การเขียนผู้ใช้ / group / อื่น ๆ ล้มเหลวด้วย คำตอบสำหรับทั้งคู่กำลังใช้ ACL และไม่ได้ปรับ IMHO การมีสิทธิ์ของเจ้าของ

NB เราได้ถลุงคำถามนี้หลังจากที่มีคำถามที่ปิดในsuperuser.com

แก้ไขแก้ไข "แต่รูปแบบกลุ่ม / เจ้าของจะไม่พอเพียง" เป็น "... กลุ่ม / อื่น ๆ ... "

ประวัติศาสตร์

ในขั้นต้นยูนิกซ์เท่านั้นที่มีสิทธิ์สำหรับผู้ใช้ที่เป็นเจ้าของและสำหรับผู้ใช้อื่น ๆ : ไม่มีกลุ่ม ดูเอกสารของ Unix รุ่น 1 โดยเฉพาะchmod(1)โดยเฉพาะอย่างยิ่ง ความเข้ากันได้แบบย้อนกลับดังนั้นหากไม่มีสิ่งอื่นใดจำเป็นต้องมีการอนุญาตสำหรับผู้ใช้ที่เป็นเจ้าของ

กลุ่มมาในภายหลัง ACLs อนุญาตให้มีกลุ่มมากกว่าหนึ่งกลุ่มในสิทธิ์ของไฟล์มามากในภายหลัง

พลังการแสดงออก

การมีสามสิทธิ์สำหรับไฟล์อนุญาตให้ใช้สิทธิ์แบบละเอียดยิ่งกว่าการมีเพียงสองสิทธิ์เท่านั้นในราคาที่ต่ำมาก (ต่ำกว่า ACLs มาก) ตัวอย่างเช่นไฟล์สามารถมีโหมดrw-r-----: เขียนได้โดยผู้ใช้ที่เป็นเจ้าของเท่านั้นสามารถอ่านได้โดยกลุ่ม

กรณีใช้งานอื่นคือ setuid executables ที่สามารถเรียกใช้งานได้โดยกลุ่มเดียวเท่านั้น ตัวอย่างเช่นโปรแกรมที่มีโหมดrwsr-x---เป็นเจ้าของroot:adminอนุญาตให้เฉพาะผู้ใช้ในadminกลุ่มเท่านั้นที่สามารถเรียกใช้โปรแกรมเป็นรูทได้

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

ความง่าย

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

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

orthogonality

แต่ละกระบวนการดำเนินการเข้าถึงระบบไฟล์ในฐานะผู้ใช้เฉพาะและกลุ่มเฉพาะ (มีกฎที่ซับซ้อนมากขึ้นเกี่ยวกับยูนิเซฟสมัยใหม่ซึ่งสนับสนุนกลุ่มเสริม) ผู้ใช้นั้นใช้หลายอย่างรวมถึงการทดสอบรูท (uid 0) และการอนุญาตให้ส่งสัญญาณ (อิงตามผู้ใช้) มีความสมมาตรตามธรรมชาติระหว่างการแยกผู้ใช้และกลุ่มในการอนุญาตกระบวนการและการแยกผู้ใช้และกลุ่มในสิทธิ์ระบบไฟล์

นี่เป็นการออกแบบโดยเจตนาหรือเป็นโปรแกรมแก้ไขหรือไม่? นั่นคือ - สิทธิ์ของเจ้าของ / กลุ่มได้รับการออกแบบและสร้างขึ้นพร้อมกับเหตุผลบางอย่างหรือว่าพวกเขามาทีละคนเพื่อตอบสนองความต้องการหรือไม่

สิทธิ์ของผู้ใช้ / กลุ่ม / อื่น ๆ ในไฟล์เป็นส่วนหนึ่งของการออกแบบ Unix ดั้งเดิม

มีสถานการณ์ที่โครงร่างผู้ใช้ / กลุ่ม / อื่น ๆ มีประโยชน์ แต่โครงร่างกลุ่ม / เจ้าของจะไม่พอเพียง?

ได้จริงทุกสถานการณ์ที่ฉันนึกได้ว่าการรักษาความปลอดภัยและการควบคุมการเข้าถึงมีความสำคัญ

ตัวอย่าง: คุณอาจต้องการที่จะให้ไบนารีบาง / สคริปต์ในระบบการดำเนินการเท่านั้นที่จะเข้าถึงotherและให้การอ่าน / เขียนเข้าถึง rootจำกัด

ฉันไม่แน่ใจว่าคุณมีรูปแบบการอนุญาตระบบไฟล์ที่มีสิทธิ์เป็นเจ้าของ / กลุ่มเท่านั้น ฉันไม่รู้ว่าคุณจะมีระบบปฏิบัติการที่ปลอดภัยได้อย่างไรหากไม่มีotherหมวดหมู่

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

ไฟล์ส่วนตัว - หาได้ง่ายมากโดยการจัดกลุ่มต่อผู้ใช้บางสิ่งที่มักจะทำเหมือนในหลาย ๆ ระบบ

จริงอยู่ที่ว่านี่เป็นเรื่องง่าย แต่มันก็เป็นเรื่องง่ายเหมือนกับการมีอยู่ของotherกลุ่ม ...

อนุญาตเฉพาะเจ้าของ (เช่นบริการระบบ) เพื่อเขียนไฟล์อนุญาตเฉพาะกลุ่มบางกลุ่มที่จะอ่านและปฏิเสธการเข้าถึงอื่น ๆ ทั้งหมด - ปัญหาของตัวอย่างนี้คือเมื่อต้องการให้กลุ่มมีสิทธิ์การเขียนผู้ใช้ / group / อื่น ๆ ล้มเหลวด้วย คำตอบสำหรับทั้งคู่กำลังใช้ ACL และไม่ได้ปรับ IMHO การมีสิทธิ์ของเจ้าของ

ฉันได้เน้นส่วนของคำสั่งของคุณที่ดูเหมือนจะย้ำจุดของฉันเกี่ยวกับความจำเป็นเชิงตรรกะสำหรับotherหมวดหมู่ในสิทธิ์ระบบไฟล์ Unix

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

นี่เป็นการออกแบบโดยเจตนาหรือเป็นโปรแกรมแก้ไขหรือไม่? นั่นคือ - สิทธิ์ของเจ้าของ / กลุ่มได้รับการออกแบบและสร้างขึ้นพร้อมกับเหตุผลบางอย่างหรือว่าพวกเขามาทีละคนเพื่อตอบสนองความต้องการหรือไม่

ใช่นี่คือการออกแบบโดยเจตนาซึ่งมีอยู่ในระบบปฏิบัติการ UNIX ตั้งแต่วันแรก ๆ มันถูกนำไปใช้กับระบบที่หน่วยความจำวัดเป็น KB และ CPU ช้ามากตามมาตรฐานของวันนี้ ขนาดและความเร็วของการค้นหานั้นสำคัญมาก ACL จะต้องใช้พื้นที่มากขึ้นและช้าลง ในทางปฏิบัติeveryoneกลุ่มจะถูกแทนด้วยค่าสถานะความปลอดภัยอื่น ๆ

มีสถานการณ์ที่โครงร่างผู้ใช้ / กลุ่ม / อื่น ๆ มีประโยชน์ แต่โครงร่างกลุ่ม / เจ้าของจะไม่พอเพียง?

สิทธิ์ที่ฉันใช้เป็นประจำสำหรับการเข้าถึงไฟล์คือ: (ฉันใช้ค่าบิตเพื่อความเรียบง่ายและเพราะนั่นคือวิธีที่ฉันมักจะตั้งค่า)

• 600หรือ400: การเข้าถึงของผู้ใช้เท่านั้น (และใช่ฉันให้สิทธิ์การเข้าถึงแก่ผู้ใช้แบบอ่านอย่างเดียว)
• 640หรือ660: การเข้าถึงของผู้ใช้และกลุ่ม
• 644, 666หรือ664: ผู้ใช้กลุ่มและการเข้าถึงอื่น ๆ โครงการใด ๆ ที่ได้รับอนุญาตระดับสองเท่านั้นที่สามารถจัดการกับสองคนนี้สามกรณี ที่สามจะต้อง ACLs

สำหรับไดเรกทอรีและโปรแกรมที่ผมมักใช้:

• 700หรือ500: ผู้ใช้เข้าถึงเฉพาะ
• 750หรือ710กลุ่มที่เข้าถึงเฉพาะ
• 755, 777, 775หรือ751: ผู้ใช้กลุ่มและการเข้าถึงอื่น ๆ ความคิดเห็นเดียวกันใช้เป็นไฟล์

ข้างต้นเป็นรายการที่ใช้บ่อยที่สุด แต่ไม่ใช่รายการการตั้งค่าสิทธิ์ที่ฉันใช้ สิทธิ์ข้างต้นรวมกับกลุ่ม (บางครั้งมีบิตกลุ่มเหนียวในไดเรกทอรี) พอเพียงในทุกกรณีที่ฉันอาจใช้ ACL

ตามที่ได้รับการระบุไว้ข้างต้นมันง่ายมากที่จะแสดงรายการการอนุญาตในรายการไดเรกทอรี หากไม่ได้ใช้ ACL ฉันสามารถตรวจสอบสิทธิ์การเข้าถึงโดยมีเพียงรายชื่อไดเรกทอรี เมื่อฉันทำงานกับระบบที่ใช้ ACL ฉันพบว่ามันยากมากในการตรวจสอบหรือตรวจสอบสิทธิ์

ระบบการอนุญาตผู้ใช้ / กลุ่ม / อื่น ๆ ได้รับการออกแบบก่อนที่ ACL จะถูกประดิษฐ์ มันกลับไปสู่ยุคแรก ๆ ของ UNIX ดังนั้นคุณไม่สามารถพูดได้ว่าปัญหาควรได้รับการแก้ไขด้วย ACL แม้ว่าแนวคิดของ ACL ดูเหมือนจะชัดเจน แต่ก็มีส่วนเกี่ยวข้องจำนวนมากสำหรับค่าใช้จ่ายพิเศษในการจัดเก็บและจัดการข้อมูลจำนวนสิทธิ์ที่อนุญาตสำหรับแต่ละไฟล์แทนที่จะเป็นจำนวนคงที่

ใช้ ACL ของทุกอย่างยังหมายความว่าคุณไม่ได้มีส่วนย่อยที่ดีที่กำหนดของข้อมูลที่ได้รับอนุญาตที่สามารถแสดง "ได้อย่างรวดเร็ว" เอาต์พุตสำหรับls -lแสดงสิทธิ์มาตรฐาน (ผู้ใช้ / กลุ่ม / อื่น ๆ ) ชื่อของผู้ใช้และกลุ่มและสัญลักษณ์เพิ่มเติม (เช่น+หรือ@เครื่องหมาย) ในรายการที่มี ACL ที่เชื่อมโยงกับพวกเขาทั้งหมดในหนึ่งบรรทัด ระบบของคุณต้องการให้ระบุกลุ่ม "สองอันดับแรก" ใน ACL เพื่อให้มีฟังก์ชันการทำงานที่เทียบเท่า

ในฐานะที่เป็นจุดเพิ่มเติมไฟล์ที่ยังคงต้องมีเจ้าของในรูปแบบ UNIX เพราะ UNIX ACLs ไม่ให้สำหรับผู้ที่ได้รับอนุญาตให้ปรับเปลี่ยน ACL