การอนุญาตของไฟล์มีผลกับ symlink อย่างไร

สมมติว่าคุณมีโครงสร้างนี้:

+ directory
-- file1
-- file2
-- file3 -> /tmp/file3

file3เป็นลิงค์ไปยังที่file3อื่นในระบบ

ตอนนี้สมมติว่าฉันchmod 777เป็นไดเรกทอรีและเนื้อหาทั้งหมดที่อยู่ภายใน ไม่ฉันfile3ใน/tmpได้รับสิทธิ์เหล่านั้นหรือไม่ นอกจากนี้สมมติว่าเรามีสถานการณ์เดียวกัน แต่กลับกัน

/tmp/file3 -> /directory/file3

หากฉันใช้การอนุญาตกับไฟล์ที่กำลังลิงก์ไปนั้นจะมีผลกับลิงค์อย่างไร

ขึ้นอยู่กับวิธีการโทรchmodและแพลตฟอร์มที่คุณใช้งาน

ตัวอย่างเช่นบนระบบ Linux man chmodบอกว่า:

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

อย่างไรก็ตามใน Mac สามารถใช้ chmod เพื่อแก้ไขการอนุญาตของลิงก์สัญลักษณ์โดยใช้ตัวเลือกเช่นนี้ (จากman chmod):

-h หากไฟล์เป็นลิงค์สัญลักษณ์ให้เปลี่ยนโหมดของลิงค์เองแทนที่จะเป็นไฟล์ที่ลิงค์ชี้ไป

เพื่อประโยชน์ของตัวอย่างสมมติว่าคุณอยู่ในเครื่อง Linux สำหรับคำตอบที่เหลือ

หากในกรณีแรกที่คุณเรียกใช้chmod -R 777 directoryเพื่อเปลี่ยนการอนุญาตซ้ำเป้าหมายลิงก์จะไม่ได้รับผลกระทบ แต่หากคุณทำเช่นchmod 777 directory/*นั้น

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

บันทึกการทดสอบสำหรับภาพประกอบ:

$ mkdir dir && touch dir/file{1,2} /tmp/file3 && ln -s {/tmp,dir}/file3
$ ls -l dir/* /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 dir/file1
-rw-r--r-- 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

$ chmod -R 777 dir && ls -l dir/* /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 /tmp/file3
-rwxrwxrwx 1 user group  0 2011-06-27 22:02 dir/file1
-rwxrwxrwx 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

$ chmod 700 dir/* && ls -l dir/* /tmp/file3
-rwx------ 1 user group  0 2011-06-27 22:02 /tmp/file3
-rwx------ 1 user group  0 2011-06-27 22:02 dir/file1
-rwx------ 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

คำตอบของ baraboom และ peth นั้นถูกต้องทั้งสอง: บิตการอนุญาตในลิงก์สัญลักษณ์นั้นไม่เกี่ยวข้อง (ยกเว้นใน macOS; ดูด้านล่าง) และการเปลี่ยนการอนุญาตบนลิงก์สัญลักษณ์ - โดยchmodเครื่องมือบรรทัดคำสั่งหรือโดยการchmod()เรียกระบบ - เพียงแค่ทำหน้าที่เป็น หากมีการดำเนินการกับเป้าหมายของลิงก์สัญลักษณ์

หากต้องการอ้างอิงคำอธิบาย SUSv4 / POSIX.1-2008 ของการเรียกระบบ symlink () :

ค่าของบิตโหมดไฟล์สำหรับลิงก์สัญลักษณ์ที่สร้างขึ้นไม่ได้ระบุไว้ อินเตอร์เฟสทั้งหมดที่ระบุโดย POSIX.1-2008 จะทำงานเสมือนว่าเนื้อหาของลิงก์สัญลักษณ์สามารถอ่านได้เสมอยกเว้นค่าบิตบิตโหมดไฟล์ที่ส่งคืนในฟิลด์st_modeของโครงสร้างstatนั้นไม่ได้ระบุไว้

ที่นี่“ ไม่ระบุ” ออกจากห้องของการตีความสำหรับการใช้งานแต่ละครั้ง ข้อมูลจำเพาะ:

• บน Linux (ทดสอบโดยใช้ ext4fs) stat()ผลตอบแทนst_mode=0777ไม่ว่า umask จะเป็นอย่างไรเมื่อสร้าง symlink ขึ้นมา ls -lดังนั้นจะแสดงlrwxrwxrwxลิงก์สัญลักษณ์เสมอ
• บน MacOS (HFS) และ FreeBSD (ทั้ง UFS และ ZFS) การเชื่อมโยงสัญลักษณ์ไม่ได้รับอนุญาตของตัวเอง: ในchmod -hคำสั่งระบุไว้ข้างต้นสามารถเปลี่ยนแปลงได้รับอนุญาตการเชื่อมโยงนี้ (ซึ่งภายในใช้ที่ไม่ใช่ POSIX lchown()เรียกระบบเพื่อให้บรรลุนี้) และstat()ระบบ st_modeเรียกผลตอบแทนที่คุ้มค่านี้

ลิงก์สัญลักษณ์บน Linux และ FreeBSD สามารถติดตามได้ตามที่ระบุโดย POSIX โดยเฉพาะอย่างยิ่งใน FreeBSD หมายความว่าโหมดไฟล์ของลิงก์สัญลักษณ์ไม่มีผลกระทบใด ๆ ต่อการควบคุมการเข้าถึง

ในทางกลับกัน macOS แบ่ง POSIX เล็กน้อย แม้ว่าลิงก์สัญลักษณ์สามารถติดตามได้โดยไม่คำนึงถึงสิทธิ์การอ่าน แต่readlink()ล้มเหลวด้วยEACCES(ปฏิเสธสิทธิ์) หากผู้ใช้ไม่มีสิทธิ์อ่าน:

$ sudo ln -shf target symlink
$ sudo chmod -h 444 symlink
$ ls -l symlink
lr--r--r--  1 root  staff  1 Mar 14 13:05 symlink -> target
$ sudo chmod -h 000 symlink
$ ls -l symlink

ls: symlink: Permission denied
l---------  1 root  staff  1 Mar 14 13:05 symlink
$ echo kthxbye > target
$ cat symlink
kthxbye

(โปรดทราบว่า-> targetส่วนที่ขาดหายไปในผลลัพธ์จากls -lคำสั่งที่สองและcat symlinkยังคงประสบความสำเร็จและพิมพ์เนื้อหาของtargetไฟล์แม้ว่าผู้ใช้จะไม่ได้รับอนุญาตให้อ่านsymlink)

เห็นได้ชัดว่า NetBSD เสนอตัวเลือกการเมาท์แบบพิเศษsympermซึ่งตั้งค่าไว้ซึ่งทำให้การเชื่อมโยงสัญลักษณ์อ่าน / เรียกใช้สิทธิ์ในการควบคุมreadlink()และการสำรวจเส้นทาง

1. วางไฟล์ลิงก์ (หลังจากตรวจสอบให้แน่ใจว่าไม่ได้ใช้กระบวนการใด ๆ )
2. ตั้ง umask ในแบบที่ 777-umask = จำเป็นต้องได้รับอนุญาตจากไฟล์
3. สร้างไฟล์ลิงค์อีกครั้ง