วัตถุประสงค์ของการอนุญาตเช่น 0111 หรือ 0333


17

วัตถุประสงค์ของการอนุญาต Linux เช่น 111 หรือ 333 คือผู้ใช้สามารถดำเนินการแต่ไม่สามารถอ่านไฟล์ได้หากความสามารถในการดำเนินการไม่ได้หมายความถึงความสามารถในการอ่านโดยอัตโนมัติ


1
คุณมีตัวอย่างของการตั้งค่าเช่นนี้หรือไม่? ฉันคิดว่าคุณถูก. คุณไม่สามารถดำเนินการสิ่งที่คุณอ่านไม่ออก ชุดค่าผสมเหล่านี้เป็นเพียงทฤษฎีในพื้นที่ของการอนุญาตระหว่าง 0000 และ 0777 โปรดทราบว่าควรเพิ่ม 0 นำหน้าเพื่อแสดงฐานฐานแปดของตัวเลข
ikrabbe

6
ยกเว้นว่ามันเป็นสคริปต์ (เช่น shell-script) คุณไม่จำเป็นต้องได้รับอนุญาตให้อ่านเพื่อดำเนินการคำสั่ง ปฏิบัติการ "ปกติ" - เช่น su, bash หรือ vi - เพียงแค่ต้องการตั้งค่าปฏิบัติการบิตเพื่อให้ผู้ใช้สามารถเรียกใช้ ไฟล์ที่อ่านไม่ได้ไม่สามารถคัดลอกได้ ดังนั้นโดยไม่อนุญาตให้ผู้ใช้คัดลอกคำสั่งที่สำคัญด้านความปลอดภัย (เช่น su) เขาป้องกันไม่ให้ทำสำเนาของเขาเอง - และจากการพยายามแยกมัน * BSD มีหลายคำสั่งที่มีการดำเนินการ แต่ไม่ได้รับอนุญาตให้อ่าน
Baard Kopperud

คำตอบ:


25

ฉันเล่นกับมันและเห็นได้ชัดว่าสิทธิ์ exec ไม่ได้หมายถึงสิทธิ์ ไบนารีสามารถปฏิบัติการได้โดยไม่ต้องอ่านได้:

$ echo 'int main(){ puts("hello world"); }' > hw.c
$ make hw
$ ./hw
hello world
$ chmod 111 hw
$ ./hw 
hello world
$ cat hw
/bin/cat: hw: Permission denied

ฉันไม่สามารถเรียกใช้งานสคริปต์ได้เว้นแต่จะมีทั้งบิตการอ่านและการอนุญาตให้ทำงานบน:

$ cat > hw.sh
#!/bin/bash
echo hello world from bash
^D
$ chmod +x ./hw.sh
$ ./hw.sh 
hello world from bash
$ chmod 111 ./hw.sh
$ ./hw.sh
/bin/bash: ./hw.sh: Permission denied

4
สิ่งนี้ถูกต้องเนื่องจากตัวอย่างที่สองใช้ #! เพื่อเริ่มต้นเนื่องจากมันพลาดส่วนหัวของเอลฟ์และต้องการให้ไฟล์อ่านได้เพื่อให้เดาได้ว่าไฟล์ใดที่สามารถใช้งานได้ นี่เป็นสถานการณ์ทั่วไปที่คุณต้องการปกป้องเนื้อหาของไฟล์จากการคัดลอกไปยังตำแหน่งอื่น ตัวจัดการสิทธิ์การใช้งานเป็นตัวอย่างทั่วไปที่คุณจะเห็นสิ่งนี้
hspaans

1
โปรดทราบว่าคุณยังสามารถอ่านไบนารีที่รันได้เท่านั้น: unix.stackexchange.com/a/34294
小太郎

6
@hspaans: shebang ถูกจัดการโดยเคอร์เนลและเคอร์เนลไม่สนใจเรื่องเล็ก ๆ น้อย ๆ ที่แปลกประหลาดเช่นการอนุญาต มันคือเชลล์ (หรือล่าม) ซึ่งต้องการการเข้าถึงแบบอ่าน เคอร์เนลทำงาน (พูด) /bin/bash hw.shแล้วทุบตีพยายามเปิดhw.shอ่าน (และล้มเหลว)
Kevin

2
ฉันหวังเป็นอย่างยิ่งว่าเคอร์เนลจะให้ความสำคัญกับการอนุญาต ไม่มีอะไรทำ สิ่งที่ประโยคที่น่ากลัวในการโพสต์ของ @ Kevin หมายถึงว่าเคอร์เนลต้องการสิทธิ์ในการเรียกใช้ไฟล์เอ็กซีคิวต์โดยไม่คำนึงถึงว่าพวกเขาใช้ Shebang หรือไม่
Emil Jeřábekสนับสนุน Monica

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

16

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


5
ที่ Uni ของฉันการอนุญาตเหล่านี้ถูกใช้เพื่อส่งการมอบหมายไปยังไดเรกทอรีโดยที่นักเรียนไม่เห็นว่าคนอื่นทำงาน ผู้บรรยายเป็นคนขี้เกียจ
DarkHeart

@DarkHeart ที่น่าสนใจ ฉันหวังว่าคุณจะต้องเพิ่มองค์ประกอบแบบสุ่มลงในชื่อไฟล์เพราะมิฉะนั้นหากนั่นไม่ใช่แรงจูงใจที่จะลองและคัดลอกจากเพื่อนร่วมชั้นของคุณฉันก็ไม่รู้ว่ามันคืออะไร
PSkocik

5

เห็นได้ชัดว่าไม่ใช่ชุดค่าผสมทั้งหมดที่มีประโยชน์ แต่จะนำชุดที่คุณกล่าวถึงโดยเฉพาะ ... จริง ๆ แล้วคุณไม่จำเป็นต้องreadได้รับอนุญาตให้ดำเนินการไฟล์ - executeสิทธิ์เท่านั้น- เว้นแต่ไฟล์ที่สงสัยคือสคริปต์ (เช่นเชลล์สคริปต์) ( .sh), perl-script ( .pl) และอื่น ๆ ) ไบนารีปกติสามารถดำเนินการได้ด้วยการexecuteอนุญาต เมื่อวันที่ * BSD-systmes หลาย executables จะช่วยให้executeได้รับอนุญาตโดยไม่ต้องreadpermisson โดยเฉพาะอย่างยิ่ง "ที่สำคัญการรักษาความปลอดภัย" คำสั่ง - suเช่น

ดังนั้นทำไมไม่ให้ผู้ใช้ - การreadรับ (และเพียงแค่ - executepermisson)? เป็นไฟล์ที่ผู้ใช้ไม่สามารถอ่านได้และผู้ใช้รายนั้นไม่สามารถคัดลอกได้! การลบการreadอนุญาตป้องกันผู้ใช้จากการทำสำเนาไฟล์ส่วนบุคคลของตนเองซึ่งในภายหลังผู้ใช้เหล่านั้นอาจถูกละเมิด (เช่นรับSUID=root on)

และไม่มีการwriteส่ง - ป้องกันไฟล์จากการถูกลบโดยไม่ตั้งใจ

โปรดทราบว่าการไม่ให้หรือreadส่งwriteต่อให้กับเจ้าของเป็นเรื่องแปลก แต่บางครั้งก็อาจเป็นความคิดที่ดีที่จะป้องกันไม่ให้แม้แต่การownerลบไฟล์ แน่นอนowner- ไม่พูดถึงroot- อาจหลีกเลี่ยงมาตรการดังกล่าวหากไม่ได้อยู่ในรูปแบบอื่นแล้วเพียงแค่chmodได้รับอนุญาตจากไฟล์


"อาจเป็นความคิดที่ดีที่จะป้องกันไม่ให้แม้แต่การownerลบไฟล์" - ยกเว้นว่าคุณไม่ต้องการการอนุญาตใด ๆ ในไฟล์ (อ่านเขียนหรือดำเนินการ) เพื่อลบ
Celada

executables ที่พร้อมใช้งานเท่านั้นสามารถใช้งานได้เช่นถ้า executable ฝังรหัสผ่านฐานข้อมูลที่ใช้เมื่อทำงานเพื่อเชื่อมต่อกับฐานข้อมูลและทำงาน แต่ไม่จำเป็นต้องเปิดเผยรหัสผ่าน
Celada

@ Celada เป็นคำถามเก่า แต่จะไม่เป็นวิธีการที่ไวต่อการทุ่มตลาดหน่วยความจำผ่านการค้นหาพื้นที่หน่วยความจำ offsets ใน/proc/${PID}/mapsแล้วอ่านส่วนที่เกี่ยวข้องของหน่วยความจำจาก/proc/${PID}/mem? หรือการ จำกัด สิทธิ์ในไฟล์ของไฟล์ที่เรียกทำงานได้นั้น จำกัด สิทธิ์การอ่านในส่วนที่เกี่ยวข้องในหน่วยความจำระหว่างการทำงานหรือไม่? (หลังดูเหมือนไม่น่าเป็นไปได้ IMO.)
Spencer D
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.