ความรู้ก่อนเรียน: ควรเข้าใจจากหัวข้อ 36 ว่าระบบปฏิบัติการรับคำขอจากแอปผ่านบริการของระบบ ตรวจสิทธิ์ และจัดการ Storage หากยังไม่คุ้นกับแนวคิด Process, System Call และ Kernel ให้ทบทวนบทก่อนหน้าแล้วกลับมาเริ่มที่คำว่า “ใครกำลังขอทำอะไรกับไฟล์ใด”
PATH 01 · พื้นฐานคอมพิวเตอร์และภาพรวม AI
คำตอบสั้น: ไฟล์คือทรัพยากรที่เก็บเนื้อหาและข้อมูลกำกับ โฟลเดอร์หรือ Directory คือโครงสร้างที่ผูกชื่อเข้ากับไฟล์และโฟลเดอร์อื่น Path คือเส้นทางที่ระบบใช้ค้นหาทรัพยากร ส่วน Permission คือกติกาที่ตัดสินว่า User หรือ Process ใดมีสิทธิ์อ่าน เปลี่ยน สร้าง ลบ หรือเรียกใช้ทรัพยากรนั้นได้
การเปิดเอกสารหนึ่งไฟล์จึงไม่ใช่แค่ดับเบิลคลิกแล้วข้อมูลปรากฏ แอปต้องส่งคำขอพร้อมตัวตนและชนิดการเข้าถึง ระบบต้องตีความ Path เดินผ่านโฟลเดอร์แต่ละระดับ ตรวจ Owner, Group, Permission หรือ ACL แล้วจึงเปิด Handle หรือ File Descriptor ให้ Process ใช้งาน หากด่านใดไม่ผ่าน เราอาจเห็นข้อความ Permission denied, Access is denied หรือคำเตือนว่าแอปไม่มีสิทธิ์เข้าถึงตำแหน่งนั้น
NOX ชวนจำประโยคเดียว: สิทธิ์ไม่ได้ถามว่า “ไฟล์นี้ปลอดภัยไหม” แต่ถามว่า “ตัวตนนี้ ขอทำการกระทำนี้ กับทรัพยากรนี้ ภายใต้กติกาใด”
เรียนจบแล้วควรทำอะไรได้
- อธิบายความต่างระหว่าง File, Folder/Directory, Path, Metadata และ File System ได้โดยไม่ปนกัน
- แยก Absolute Path ออกจาก Relative Path และตามการค้นหา Path ทีละส่วนได้
- อธิบาย Owner, Group, Read, Write, Execute/Search, ACL และ Permission inheritance ในระดับใช้งานได้
- วิเคราะห์ Permission denied จากตัวตน การกระทำ ทรัพยากร และเส้นทาง แทนการเปิดสิทธิ์กว้างทั้งระบบ
- จัดทำ Access Journey Card เพื่อบันทึกหลักฐาน ทดลองแก้ทีละตัวแปร และย้อนกลับได้
ภาพจำหลัก: ที่อยู่ ประตู กุญแจ และผู้ขอใช้
ลองนึกถึงอาคารสำนักงาน ไฟล์คือห้องที่เก็บของ โฟลเดอร์คือชั้นและทางเดิน Path คือที่อยู่ที่ระบุว่าจะไปห้องใด Permission คือกติกาของประตู แต่ภาพจำนี้ยังขาดสิ่งสำคัญอีกอย่างคือ ผู้ขอใช้ เพราะประตูบานเดียวกันอาจเปิดให้เจ้าของ เปิดให้อีกทีมอ่านอย่างเดียว และปฏิเสธบุคคลภายนอก
ในคอมพิวเตอร์ ผู้ขอใช้จริงมักเป็น Process ที่ทำงานภายใต้ตัวตนของผู้ใช้ แอปแก้ไขภาพ โปรแกรมสำรองข้อมูล สคริปต์ Python และ File Explorer อาจเข้าถึงไฟล์เดียวกัน แต่ถือ Token, กลุ่ม, Sandbox หรือสิทธิ์ยกระดับไม่เหมือนกัน จึงเป็นไปได้ว่าเปิดไฟล์ด้วยโปรแกรมหนึ่งได้ แต่อีกโปรแกรมกลับถูกปฏิเสธ
เส้นทางยังสำคัญพอ ๆ กับปลายทาง ต่อให้ไฟล์ปลายทางอนุญาตให้อ่าน หาก Process เดินผ่านโฟลเดอร์ชั้นใดชั้นหนึ่งไม่ได้ คำขอก็ไปไม่ถึงไฟล์นั้น ในทางกลับกัน การลบหรือเปลี่ยนชื่อไฟล์มักเกี่ยวกับสิทธิ์บนโฟลเดอร์แม่ เพราะการกระทำนั้นเปลี่ยนรายการชื่อที่โฟลเดอร์เก็บไว้ ไม่ได้แก้เฉพาะเนื้อหาภายในไฟล์
File กับ Folder ต่างกันตรงไหน
File ไม่ได้มีแค่เนื้อหา
เมื่อพูดว่า “ไฟล์รายงาน” เรามักนึกถึงข้อความ ตาราง หรือรูปภาพที่เปิดเห็น แต่ระบบไฟล์ต้องเก็บข้อมูลกำกับอีกหลายอย่าง เช่น ชนิดวัตถุ ขนาด เวลาแก้ไข เจ้าของ กลุ่ม Permission และตำแหน่งของข้อมูลบน Storage เนื้อหากับ Metadata จึงเป็นคนละส่วน แม้ทั้งสองทำให้ไฟล์ใช้งานได้ร่วมกัน
นามสกุลอย่าง .pdf, .docx หรือ .py เป็นส่วนหนึ่งของชื่อ ช่วยให้คนและโปรแกรมเดาชนิดข้อมูล แต่ไม่ใช่หลักฐานเด็ดขาดว่าเนื้อหาด้านในเป็นชนิดนั้น การเปลี่ยนชื่อ photo.jpg เป็น photo.pdf ไม่ได้แปลงภาพให้เป็น PDF โปรแกรมที่ปลอดภัยควรตรวจรูปแบบจริง ไม่ตัดสินจากนามสกุลเพียงอย่างเดียว
Folder หรือ Directory คือโครงสร้างชื่อ
ในภาษาผู้ใช้ “โฟลเดอร์” เป็นภาพของแฟ้มใส่เอกสาร ส่วนเอกสารระบบมักใช้คำว่า Directory เพราะเน้นบทบาทเป็นสารบัญที่ผูกชื่อเข้ากับรายการอื่น Directory หนึ่งอาจมีชื่อของไฟล์ ชื่อ Directory ย่อย และชื่อที่เป็น Link จึงสร้างลำดับชั้นที่เราใช้จัดโครงการ เช่น project/data/raw, project/notebooks และ project/models
การย้ายไฟล์ภายใน File System เดียวกันอาจเป็นการเปลี่ยนรายการชื่อหรือ Directory entry มากกว่าคัดลอกเนื้อหาทั้งก้อน แต่รายละเอียดจริงขึ้นกับระบบไฟล์ ตำแหน่ง และเครื่องมือที่ใช้ เราจึงไม่ควรสรุปว่าการ Move กับ Copy มีผลต่อ Permission เหมือนกันทุกแพลตฟอร์ม ต้องดูว่าไฟล์ใหม่ถูกสร้างขึ้นหรือเพียงเปลี่ยนชื่อ และระบบมีการสืบทอด ACL อย่างไร
| แนวคิด | คำถามที่ตอบ | ตัวอย่างหลักฐาน | ข้อควรระวัง |
|---|---|---|---|
| File content | ข้อมูลด้านในคืออะไร | ข้อความ ไบต์ รูปภาพ โค้ด โมเดล | นามสกุลอาจไม่ตรงเนื้อหา |
| Metadata | ไฟล์มีสถานะและเจ้าของอย่างไร | Size, time, owner, mode, ACL | Timestamp แต่ละชนิดมีความหมายต่างกัน |
| Directory entry | ชื่อนี้อ้างถึงวัตถุใด | ชื่อไฟล์ในโฟลเดอร์ | ลบชื่อไม่เหมือนล้างเนื้อหาทันทีในทุกกรณี |
| Path | จะค้นหาวัตถุจากจุดเริ่มใด | C:\Users\Nox\report.txt หรือ /home/nox/report.txt | Relative path เปลี่ยนความหมายตาม Current directory |
Path คือประโยคบอกทาง ไม่ใช่ตัวไฟล์
Path เป็นข้อความที่ระบบใช้ค้นหาชื่อทีละส่วน บน Windows เราคุ้นกับ Drive letter และ Backslash เช่น C:\Users\Nox\Documents\report.txt รวมถึง UNC path สำหรับ Network share เช่น \\server\team\report.txt บนระบบแบบ Unix เรามักเห็น Slash และ Root เช่น /home/nox/documents/report.txt กฎการตั้งชื่อ อักขระต้องห้าม ความยาว และ Case sensitivity แตกต่างตามระบบปฏิบัติการและ File System จึงควรหลีกเลี่ยงการเดาจากหน้าตาเพียงอย่างเดียว
Absolute Path
Absolute Path ระบุจุดเริ่มชัด เช่น Root, Drive หรือ Network share ทำให้ความหมายคงที่มากกว่าเมื่อส่งให้โปรแกรมอื่น อย่างไรก็ตาม “คงที่” ไม่ได้แปลว่าใช้ได้ทุกเครื่อง เพราะ Drive, ชื่อ User, Mount point และโครงสร้างโฟลเดอร์อาจไม่เหมือนกัน การฝัง Absolute Path จากเครื่องผู้พัฒนาไว้ในโค้ดจึงเป็นสาเหตุคลาสสิกของคำว่า “เครื่องฉันใช้ได้”
Relative Path
Relative Path เริ่มจาก Current working directory หรือฐานที่ API กำหนด เช่น data/train.csv และ ../config.json จุดแข็งคือย้ายโครงการทั้งชุดได้ง่าย แต่ความหมายอาจเปลี่ยนเมื่อเปิดโปรแกรมจากคนละโฟลเดอร์ รันผ่าน Scheduler, Notebook, IDE หรือ Container วิธีตรวจคือพิมพ์หรือบันทึก Current working directory และ Resolved path ก่อนเปิดไฟล์
จุดและสองจุด
ในหลายระบบ . หมายถึง Directory ปัจจุบัน ส่วน .. หมายถึง Directory แม่ การประกอบ Path ที่รับมาจากผู้ใช้โดยไม่ตรวจขอบเขตอาจเปิดช่องให้ Path traversal หลุดออกจากโฟลเดอร์ที่ตั้งใจ แอปจึงควร Normalize และตรวจว่า Resolved path ยังอยู่ใต้ฐานที่อนุญาต ไม่ใช่เพียงค้นหาอักขระ .. แบบผิวเผิน
ระบบตาม Path อย่างไร: ตรวจทุกประตู ไม่กระโดดถึงปลายทาง
เมื่อ Process ขอเปิด /home/nox/project/data.csv ระบบไม่ได้ค้นหาชื่อเต็มในครั้งเดียว แต่เริ่มจากจุดฐาน แล้วค้นหา home, nox, project และ data.csv ตามลำดับ แต่ละ Directory ต้องมีรายการชื่อตรงกัน และ Process ต้องมีสิทธิ์ Search/Traverse ที่เพียงพอเพื่อเดินต่อ
- กำหนดจุดเริ่ม: Path แบบ Absolute เริ่มจาก Root ส่วน Relative เริ่มจาก Current directory หรือ Directory handle ที่ API ระบุ
- แยก Component: ระบบพิจารณาชื่อทีละส่วน พร้อมจัดการ
.,..และกฎ Namespace - ค้นหารายการชื่อ: File System หา Directory entry แล้วเชื่อมไปยังข้อมูลกำกับของวัตถุ เช่น Inode หรือโครงสร้างเทียบเท่า
- ตรวจสิทธิ์ระหว่างทาง: หาก Directory ชั้นหนึ่งไม่อนุญาตให้ Search/Traverse การค้นหาหยุด แม้ไฟล์ปลายทางจะ Readable
- จัดการ Link: หากพบ Symbolic link หรือ Reparse mechanism ระบบอาจเปลี่ยนเส้นทางตามกฎและข้อจำกัด
- ตรวจการกระทำปลายทาง: Read, Write, Execute, Create, Delete และ Rename ต้องการสิทธิ์ไม่เหมือนกัน
- คืน Handle: เมื่อผ่าน ระบบสร้าง Handle/File Descriptor ที่ผูกกับสิทธิ์ที่อนุมัติให้ Process ใช้ต่อ
ความเข้าใจนี้ช่วยอธิบายเหตุการณ์ที่ดูขัดกัน เช่น User อ่าน Metadata ของไฟล์ได้จากรายการ แต่เปิดเนื้อหาไม่ได้ หรือเปิดไฟล์ได้แต่ลบไม่ได้ สองการกระทำนี้เดินผ่านกฎคนละชุด การแก้ปัญหาจึงต้องระบุ Operation ให้ชัด ไม่ใช้คำกว้างว่า “เข้าไม่ได้”
Metadata คือหลักฐานรอบไฟล์
Metadata ช่วยตอบว่าไฟล์เป็นของใคร เปลี่ยนเมื่อใด ใหญ่เท่าไร และมีกติกาอะไร แต่แต่ละแพลตฟอร์มและ File System เก็บรายละเอียดต่างกัน บางระบบมี File attributes, Extended attributes, Alternate streams, ACL, Security labels หรือ Flags เพิ่มเติม การดูเพียงบรรทัดเดียวจากคำสั่งหนึ่งจึงอาจไม่เห็นกติกาทั้งหมด
Identity
Owner, Group, Security identifier และผู้สร้าง ช่วยระบุว่า Subject ใดอยู่ใน Class หรือ ACE ใด
State
Size, type, link count, timestamps และ attributes ช่วยแยกไฟล์ปกติ Directory และ Link
Policy
Mode bits, ACL, inheritance, labels และ sandbox policy เป็นหลักฐานการตัดสินสิทธิ์
Timestamp ต้องอ่านอย่างระมัดระวัง เวลาแก้เนื้อหา เวลาเข้าถึง เวลาเปลี่ยน Metadata และเวลาเกิดไฟล์อาจมีชื่อและพฤติกรรมต่างกัน การ Copy, Restore, Sync หรือ Extract archive อาจทำให้บางเวลาถูกเก็บ บางเวลาถูกสร้างใหม่ จึงไม่ควรใช้ Timestamp ช่องเดียวสรุปว่าใครทำอะไรโดยไม่มี Log หรือหลักฐานอื่นประกอบ
Metadata ยังไม่ใช่การเข้ารหัส Permission ควบคุมว่าใครขอใช้ผ่านระบบได้ ส่วน Encryption ปกป้องเนื้อหาด้วยกุญแจ แม้ผู้โจมตีจะอ่าน Storage ดิบได้ ทั้งสองกลไกช่วยกันแต่แทนกันไม่ได้ การเปิดสิทธิ์อ่านไม่ได้มอบกุญแจถอดรหัสเสมอ และการเข้ารหัสไม่ได้กำหนด Workflow การแก้ไข ลบ หรือแชร์โดยอัตโนมัติ
Permission model: ใคร ทำอะไร กับอะไร
บนระบบแบบ Unix โมเดลพื้นฐานแบ่ง Class เป็น Owner, Group และ Other แล้วกำหนด Read, Write และ Execute/Search ส่วน Windows ใช้ Security descriptor และ ACL ที่ประกอบด้วยรายการควบคุมการเข้าถึง ระบบนำ Access token ของ Thread/Process มาเทียบกับกติกาของไฟล์หรือ Directory โมเดลทั้งสองไม่เหมือนกันทุกจุด แต่แชร์คำถามหลักเดียวกัน
| องค์ประกอบ | คำถาม | ตัวอย่าง | หลักฐานที่ควรเก็บ |
|---|---|---|---|
| Subject | ใครหรือ Process ใดกำลังขอ | User, Service account, Container process | User ID, Group, Token, App identity |
| Operation | ขอทำอะไร | Read, Write, Execute, Delete, Rename | คำสั่ง/API และ Error code |
| Object | ทรัพยากรใด | ไฟล์, Parent directory, Link, Share | Resolved path และชนิดวัตถุ |
| Policy | กติกาใดตัดสิน | Mode bits, ACL, inheritance, sandbox | Owner, Group, ACE และ Policy ที่เกี่ยวข้อง |
| Context | เกิดที่ไหนและเมื่อใด | Local, Network, Cloud, Container | เครื่อง, Session, Mount, เวลา และ Log |
Read ไม่ได้แปลว่า Write
สิทธิ์อ่านเปิดทางให้ Process รับเนื้อหาหรือข้อมูลบางชนิด สิทธิ์เขียนอนุญาตให้เปลี่ยนเนื้อหา แต่การลบหรือเปลี่ยนชื่ออาจถูกตัดสินจาก Directory แม่ การ Execute เป็นอีกความสามารถหนึ่ง ไม่ควรถูกมอบเพียงเพราะไฟล์อ่านได้ โดยเฉพาะไฟล์จากอินเทอร์เน็ตหรือแหล่งที่ไม่เชื่อถือ
Least privilege
หลัก Least privilege คือให้สิทธิ์เท่าที่จำเป็นต่อหน้าที่และระยะเวลาที่จำเป็น ไม่ใช่ให้ Administrator หรือ Full Control เป็นค่าเริ่มต้น เป้าหมายไม่ใช่ทำให้ทุกอย่าง “ล็อกมากที่สุด” แต่ให้เส้นทางงานปกติเดินได้ พร้อมจำกัดผลกระทบเมื่อบัญชี แอป หรือไฟล์ถูกนำไปใช้ผิดทาง
สิทธิ์ของ Directory ไม่เหมือนสิทธิ์ของไฟล์
จุดที่ผู้เริ่มต้นสับสนมากที่สุดคือความหมายของ Read, Write และ Execute บน Directory ในโมเดลแบบ POSIX โดยสรุป Read เกี่ยวกับการอ่านรายชื่อภายใน Write เกี่ยวกับการเพิ่ม ลบ หรือเปลี่ยน Directory entry และ Execute มักหมายถึง Search/Traverse เพื่อเข้าถึงชื่อภายใน ความสามารถจริงเกิดจากการผสมหลายสิทธิ์และกฎเสริม ไม่ใช่ดูตัวอักษรเดียว
ตัวอย่างเช่น หากมี Read แต่ไม่มี Search ผู้ใช้อาจเห็นรายชื่อบางอย่างแต่เข้าถึง Metadata หรือเนื้อหาด้านในตามชื่อไม่ได้ตามปกติ หากมี Search แต่ไม่มี Read ผู้ใช้อาจเข้าถึงชื่อที่รู้ล่วงหน้าได้ แต่ List รายการทั้งหมดไม่ได้ หากมี Write และ Search บน Parent directory การลบหรือเปลี่ยนชื่อรายการอาจเป็นไปได้แม้ผู้ใช้ไม่ได้เขียนเนื้อหาไฟล์นั้นโดยตรง ทั้งนี้ Sticky bit, ACL และนโยบายอื่นอาจเพิ่มข้อจำกัด
เลข 4, 2, 1 คือการเข้ารหัส ไม่ใช่เป้าหมาย
ในการแสดง Permission แบบ Octal ค่า Read เท่ากับ 4, Write เท่ากับ 2 และ Execute เท่ากับ 1 จึงรวมเป็น 7 สำหรับ rwx, 6 สำหรับ rw- และ 5 สำหรับ r-x แต่การจำ 755 หรือ 644 โดยไม่เข้าใจ Owner, Group, Other และชนิดวัตถุอาจนำไปใช้ผิด โดยเฉพาะเมื่อคำสั่งทำงานแบบ Recursive
ก่อนเปลี่ยน Permission ให้เขียนเป็นประโยคก่อน เช่น “เจ้าของต้องอ่านและแก้ไฟล์ได้ สมาชิกทีมอ่านได้ บุคคลอื่นไม่เข้าถึง” แล้วจึงแปลงเป็นกติกาของแพลตฟอร์ม วิธีนี้ลดการเลือกเลขจากคำตอบบนเว็บแบบไม่เข้าใจบริบท และทำให้ตรวจผลหลังเปลี่ยนได้
Windows ACL และ Permission inheritance
บน Windows ไฟล์และ Directory เป็น Securable objects ที่มี Security descriptor ระบบเทียบสิทธิ์ที่ Process ขอ กับ Access token และรายการใน ACL เพื่อพิจารณาว่าจะคืน Handle พร้อมสิทธิ์ใด รายการอาจผูกกับ User, Group หรือ Security identifier และมีรายละเอียดมากกว่าคำว่า Read/Write ที่แสดงในหน้าต่างทั่วไป
Inheritance ช่วยให้ไฟล์และโฟลเดอร์ลูกได้รับกติกาจาก Container แม่ ทำให้บริหารทั้งโครงสร้างได้สม่ำเสมอ แต่เมื่อมี Explicit permission, กลุ่มหลายชั้น หรือรายการ Deny การคาดเดาจากป้ายเดียวอาจผิด ควรดู Effective access ของตัวตนจริง และแยกกติกาที่สืบทอดออกจากกติกาที่ตั้งเฉพาะจุด
การ Copy มักสร้างวัตถุใหม่ที่ปลายทางและอาจรับกติกาของปลายทาง ส่วน Move ภายในขอบเขตเดียวกันอาจมีพฤติกรรมต่างออกไป รายละเอียดขึ้นกับ File System เครื่องมือ และข้าม Volume หรือไม่ จึงไม่ควรจำสูตรเดียวแล้วใช้กับทุกกรณี หลัง Copy, Move, Restore หรือ Extract archive ควรตรวจ Owner และ Effective permission ที่ปลายทางจริง
Local permission, App privacy และ Cloud sharing เป็นคนละชั้น
แม้ ACL ท้องถิ่นอนุญาต แอปอาจถูก Sandbox หรือ Privacy setting จำกัดไม่ให้เข้าถึง Documents, Desktop หรือ Downloads ในทางกลับกัน ไฟล์บน Cloud อาจมี Sharing link ที่เปิดให้ผู้อื่น View หรือ Edit แม้ Permission บนเครื่องของผู้สร้างดูเข้มงวด การตรวจสิทธิ์จึงต้องถามว่าไฟล์อยู่ Local, Network share, Sync folder หรือ Cloud service และใครควบคุมแต่ละชั้น
สำหรับไฟล์แชร์ ให้ตรวจทั้ง Direct access, Group access และ Link access รวมถึงสิทธิ์ View/Edit, วันหมดอายุ และความสามารถ Download การส่งลิงก์ต่ออาจขยายผู้เข้าถึงได้หากเลือกขอบเขตกว้าง การหยุดแชร์จึงต้องจัดการ Link หรือ Access entry ที่ต้นทาง ไม่ใช่ลบข้อความที่เคยส่งอย่างเดียว
Shortcut, Symbolic link และ Hard link ไม่ใช่ไฟล์สำเนา
Shortcut เป็นไฟล์หรือวัตถุช่วยนำทางในระดับผู้ใช้ Symbolic link เก็บเส้นทางไปยัง Target และถูกตีความระหว่างการค้นหา Path ส่วน Hard link เป็นชื่ออีกชื่อที่อ้างถึงข้อมูลไฟล์เดียวกันใน File System ที่รองรับ ความต่างนี้มีผลต่อการลบ ย้าย สำรองข้อมูล และตรวจสิทธิ์
Symbolic link อาจชี้ไปยัง Target ที่ไม่มีอยู่ กลายเป็น Dangling link และอาจมี .. อยู่ในเส้นทาง การตาม Link โดยไม่จำกัดขอบเขตเป็นความเสี่ยงของโปรแกรมที่รับ Path จากภายนอก จึงควรระบุว่าจะ Follow หรือไม่ ใช้ API ที่เหมาะสม และตรวจ Resolved target ก่อนเขียนหรือลบ
การลบ Symbolic link โดยตรงควรลบตัว Link ไม่ใช่ Target แต่คำสั่ง Recursive และเครื่องมือบางชนิดมีตัวเลือก Follow link ที่เปลี่ยนพฤติกรรม การสำรองข้อมูลก็ต้องตัดสินว่าจะเก็บ Link เป็น Link หรือคัดลอกเนื้อหา Target หากไม่กำหนด นโยบาย Backup อาจได้ข้อมูลซ้ำ ข้ามขอบเขต หรือพลาด Target ที่สำคัญ
| ชนิด | เก็บอะไร | เมื่อ Target ย้าย/หาย | คำถามก่อนใช้งาน |
|---|---|---|---|
| Shortcut | ข้อมูลนำทางสำหรับ Shell/แอป | อาจเปิดไม่ได้หรือค้นหาใหม่ | โปรแกรมปลายทางตีความหรือไม่ |
| Symbolic link | ข้อความ Path ไปยัง Target | อาจเป็น Dangling link | เครื่องมือ Follow link หรือจัดการตัว Link |
| Hard link | ชื่ออีกชื่อของไฟล์เดียวกัน | ข้อมูลยังอยู่ตราบใดที่ยังมี Link และการอ้างอิงตามกฎระบบ | File System และขอบเขตรองรับหรือไม่ |
| Copy | วัตถุใหม่พร้อมเนื้อหาที่คัดลอก | แยกจากต้นฉบับหลังสร้าง | Metadata และ Permission ใดถูกเก็บหรือสร้างใหม่ |
หนึ่งคำสั่ง “บันทึกไฟล์” เกิดอะไรขึ้น
สมมติแอปต้องบันทึก project/output/report.csv ภาพรวมการเดินทางมีดังนี้
project และ output พร้อมตรวจสิทธิ์ระหว่างทางแอปที่ออกแบบรอบคอบมักบันทึกลงไฟล์ชั่วคราวใน Directory เดียวกัน ตรวจว่าการเขียนสำเร็จ แล้ว Rename/Replace เพื่อหลีกเลี่ยงไฟล์ครึ่งเดียวเมื่อโปรแกรมล่ม แต่คำว่า Atomic ไม่ได้ครอบคลุมทุก File System, Network share หรือ Sync service จึงต้องทดสอบบนสภาพแวดล้อมจริงและมี Backup สำหรับข้อมูลสำคัญ
หากขั้น Resolve ผิด เราได้ File not found หรือบันทึกผิดที่ หาก Traverse ไม่ผ่าน เราได้ Permission denied หาก Parent เขียนไม่ได้ เราสร้างหรือ Rename ไม่ได้ หาก Storage เต็ม Quota หมด หรือ Network หลุด การเขียนอาจล้มเหลวหลังเปิดได้แล้ว ข้อความ “บันทึกไม่ได้” จึงเป็นปลายทางของหลายสาเหตุ ต้องจับขั้นที่ล้มให้ได้
CASE STUDY
Notebook อ่านข้อมูลได้ แต่บันทึกผลลัพธ์ไม่ได้
ทีมวิเคราะห์ดาวน์โหลดโครงการจากระบบแชร์แล้วเปิด Notebook ได้ ตารางอ่านจาก data/input.csv สำเร็จ แต่เมื่อบันทึก output/result.csv กลับขึ้น Permission denied สมาชิกคนหนึ่งเสนอให้รัน Notebook เป็น Administrator อีกคนเสนอให้เปิดสิทธิ์ทั้งโฟลเดอร์เป็น Full Control
อาการที่เห็น
- อ่านไฟล์เดิมได้
- สร้างไฟล์ใหม่ใน
outputไม่ได้ - บันทึกไป Desktop ได้
- ผู้ใช้คนอื่นในเครื่องเดียวกันอาจได้ผลต่างกัน
สมมติฐานที่ควรแยก
- Current directory ไม่ตรงที่คิด
- โฟลเดอร์
outputไม่มี Write/Create permission - Owner หรือ ACL ติดมาจากการ Extract/Copy
- แอปถูก Sandbox หรือ Privacy setting จำกัด
- ไฟล์เดิมถูก Lock, Read-only หรือ Sync conflict
ขั้นที่ 1: ระบุคำขอให้แคบ
บันทึก Process ที่ใช้ ตัวตนที่รัน Resolved path และ Operation ว่าเป็น Create new, Append หรือ Replace อย่าเขียนเพียง “เข้าโฟลเดอร์ไม่ได้” เพราะหลักฐานบอกว่า Read สำเร็จแล้ว ปัญหาอยู่ในเส้นทาง Write/Create
ขั้นที่ 2: ตรวจ Parent directory
ตรวจ Owner, Group, ACL, Inheritance และ Effective access ของ output รวมถึง Directory ทุกชั้นก่อนหน้า เปรียบเทียบกับ Directory ที่บันทึกได้ เช่น Desktop หากโครงการอยู่ใน Sync folder หรือ Shared volume ให้ดูนโยบายอีกชั้นด้วย
ขั้นที่ 3: ทดลองแบบย้อนกลับได้
สร้างโฟลเดอร์ทดสอบขนาดเล็กใต้ตำแหน่งที่ตั้งใจ ให้สิทธิ์เฉพาะ User หรือ Group ที่ต้องใช้ แล้วลองสร้างไฟล์ชื่อใหม่หนึ่งไฟล์ หากสำเร็จ ค่อยปรับ Directory จริงแบบจุดเดียว บันทึกค่าก่อนและหลัง หลีกเลี่ยงการเปลี่ยน Recursive ทั้งโครงการจนกว่าจะเข้าใจผลต่อไฟล์ลับ สคริปต์ และ Executable
ขั้นที่ 4: ยืนยัน Workflow เดิม
รัน Notebook ด้วยวิธีเดิม ไม่ยกระดับโดยไม่จำเป็น ตรวจว่า Read, Create, Replace, Delete temporary file และ Rename ทำงานครบ เพราะบางแอปบันทึกโดยสร้างไฟล์ชั่วคราวแล้วแทนที่ไฟล์เดิม การทดสอบแค่สร้างไฟล์เปล่าจึงอาจยังไม่ครอบคลุม
วิธีแก้ Permission อย่างปลอดภัย
ด่านตรวจ 8 ข้อของ NOX
- หยุดก่อนยกระดับ: อย่าเปิด Administrator, Root หรือ Full Control เป็นการทดลองแรก
- เก็บ Error เต็ม: จดข้อความ Error code, เวลา, โปรแกรม และการกระทำที่ทำให้เกิด
- Resolve path: ยืนยัน Path จริง Current directory, Link target, Mount และ Namespace
- ยืนยัน Subject: ตรวจ User, Group, Service account, Token และ App sandbox ที่กำลังรัน
- แยก Operation: ทดสอบ List, Read, Create, Write, Rename และ Delete แยกกัน
- ตรวจ Parent: ดู Permission ของ Directory ทุกชั้น ไม่หยุดที่ไฟล์ปลายทาง
- เปลี่ยนจุดเล็ก: ให้สิทธิ์เฉพาะ User/Group และตำแหน่งที่ต้องใช้ พร้อมบันทึกค่าก่อนแก้
- ทดสอบและย้อนกลับ: รัน Workflow เดิม ตรวจผลข้างเคียง และคืนค่าหากสมมติฐานไม่ถูก
เหตุใดไม่ควรใช้ 777 หรือ Everyone: Full Control เป็นคำตอบทั่วไป
การเปิดกว้างทำให้แยกสาเหตุไม่ได้และขยายผู้ที่แก้หรือนำไฟล์ไปใช้ได้ หาก Directory มี Script, Model, Configuration หรือข้อมูลฝึก AI ผู้โจมตีหรือโปรแกรมผิดพลาดอาจเปลี่ยน Input และทำให้ Pipeline ให้ผลลัพธ์ผิดโดยไม่ต้องเจาะโมเดลโดยตรง นี่คือเหตุผลที่ File permission เป็นส่วนหนึ่งของความน่าเชื่อถือของระบบ AI
อีกปัญหาคือการเปลี่ยน Recursive อาจไล่ผ่าน Link หรือวัตถุจำนวนมาก ทำให้กติกาเฉพาะจุดสูญหาย ก่อนคำสั่งที่กระทบทั้งต้นไม้ควร Preview รายการเป้าหมาย สำรอง ACL/Metadata เมื่อเครื่องมือรองรับ และตรวจ Absolute target ว่าอยู่ในขอบเขตโครงการจริง
บทบาทของมนุษย์
ระบบให้คำตอบ Allow หรือ Deny ตาม Policy แต่คนต้องออกแบบว่าใครควรมีสิทธิ์อะไร อนุมัติข้อยกเว้น ตรวจผลกระทบ และรักษาทางอุทธรณ์ เมื่อทีมแชร์ข้อมูล ควรมีเจ้าของข้อมูลและเจ้าของระบบแยกบทบาท ผู้ใช้ไม่ควรถูกบังคับให้แก้ด้วยการขอสิทธิ์สูงสุดเพราะไม่มีช่องทางสนับสนุนที่ชัดเจน
ความเข้าใจผิดที่พบบ่อย
“เป็นเจ้าของไฟล์จึงลบได้เสมอ”
การลบเกี่ยวข้องกับ Parent directory, ACL, Sticky bit, File lock และนโยบายอื่น เจ้าของไฟล์ไม่ใช่หลักฐานเดียว
“เปิดได้แปลว่าแก้ได้”
Read, Write, Execute, Delete และ Rename เป็นคนละ Operation ระบบอาจอนุญาตบางอย่างและปฏิเสธอีกอย่าง
“เห็นใน Explorer จึงเห็นในแอป”
แอปอาจใช้คนละ Token, Sandbox, Container, Current directory หรือ Namespace
“เปลี่ยนนามสกุลก็เปลี่ยนชนิดไฟล์”
นามสกุลเป็นชื่อ ไม่ได้แปลงโครงสร้างข้อมูลด้านใน และอาจถูกใช้หลอกผู้ใช้ได้
“Permission คือ Encryption”
Permission ควบคุมคำขอผ่านระบบ ส่วน Encryption ปกป้องเนื้อหาด้วยกุญแจ ทั้งสองช่วยกันแต่ไม่แทนกัน
“ลิงก์แชร์ถูกลบจากแชตแล้วจบ”
ต้องปิด Link access หรือรายการแชร์ที่ต้นทาง และตรวจสำเนาที่ผู้อื่นอาจดาวน์โหลดไปแล้ว
Failure case: ใช้ได้ใน Terminal แต่ใช้ไม่ได้ในแอป
อย่ารีบสรุปว่าแอปมี Bug เปรียบเทียบ User identity, Environment, Working directory, Sandbox, Privacy setting และ Path ที่ Resolve จริง Terminal อาจรันภายใต้ Shell ที่ได้รับสิทธิ์แล้ว ขณะที่แอป GUI ถูกจำกัดโฟลเดอร์ หรือกลับกัน Terminal อาจเป็น Service account ที่ไม่มีสิทธิ์ของผู้ใช้ Desktop
Failure case: ย้ายไฟล์แล้วสิทธิ์เปลี่ยน
ตรวจว่าการ “ย้าย” เป็น Rename ใน File System เดิม หรือเป็น Copy แล้ว Delete ข้าม Volume/Cloud/Share ตรวจ Inherited permission ที่ปลายทาง Owner ใหม่ และ Sync policy อย่าแก้ค่ากลับตามต้นทางโดยอัตโนมัติ เพราะปลายทางอาจตั้งกติกาต่างด้วยเหตุผลด้านความปลอดภัย
WORKSHEET
Access Journey Card: ตามคำขอหนึ่งรายการจนจบ
เลือกเหตุการณ์จริงที่ย้อนกลับได้ เช่น โปรแกรมบันทึกไฟล์ไม่ได้ สคริปต์อ่าน Dataset ไม่พบ หรือเพื่อนร่วมทีมเปิดลิงก์ได้แต่แก้ไม่ได้ แล้วกรอกการ์ดนี้ก่อนเปลี่ยน Permission
- เป้าหมายงาน: ต้องการให้ใครทำงานอะไรสำเร็จ
- Subject: User, Group, Process, App identity หรือ Service account ใด
- Operation: List, Read, Create, Write, Append, Replace, Rename, Delete หรือ Execute
- Raw path: Path ที่ผู้ใช้หรือโค้ดส่งมา
- Resolved path: Absolute target หลังจัดการ Current directory และ Link
- Path checkpoints: Directory แต่ละชั้นและสิทธิ์ Traverse/Search
- Object policy: Owner, Group, Mode/ACL, Inheritance, Sandbox และ Sharing link
- Baseline: การกระทำใดสำเร็จ การกระทำใดล้มเหลว พร้อม Error เต็ม
- การเปลี่ยนจุดเดียว: Permission หรือ Policy ใดที่จะแก้ ใครอนุมัติ และย้อนกลับอย่างไร
- ผลทดสอบ: Workflow เดิมสำเร็จหรือไม่ และบุคคลที่ไม่เกี่ยวข้องยังถูกจำกัดหรือไม่
| ด่าน | หลักฐานก่อนแก้ | สมมติฐาน | การทดลอง | ผล |
|---|---|---|---|---|
| Identity | __________ | __________ | __________ | __________ |
| Path | __________ | __________ | __________ | __________ |
| Parent directory | __________ | __________ | __________ | __________ |
| File/Link | __________ | __________ | __________ | __________ |
| App/Cloud policy | __________ | __________ | __________ | __________ |
Insight Gate: ก่อนถือว่าแก้สำเร็จ คุณต้องอธิบายได้ว่าด่านใดเคยปฏิเสธ เหตุใดการเปลี่ยนใหม่จึงให้สิทธิ์พอดีกับงาน และขอบเขตใดยังถูกป้องกันอยู่
แบบทดสอบความเข้าใจ 5 ข้อ
บทสรุป: Permission เป็นการตัดสินคำขอตลอดเส้นทาง
File คือเนื้อหาและ Metadata ส่วน Folder/Directory จัดชื่อเป็นลำดับชั้น Path ทำหน้าที่บอกทางจากฐานไปยังวัตถุ ระบบต้อง Resolve ชื่อทีละส่วน ตรวจ Directory ระหว่างทาง จัดการ Link และตรวจ Operation ที่ปลายทาง ก่อนคืน Handle ให้ Process ใช้
สิทธิ์จึงไม่ได้อยู่ที่ไฟล์ปลายทางอย่างเดียว Read, Write, Execute, Delete และ Rename มีเงื่อนไขต่างกัน Directory มีความหมายของ Read/Write/Search ของตนเอง Windows ACL และ Inheritance เพิ่มรายละเอียด ส่วน App sandbox, Network share และ Cloud sharing อาจวางกติกาอีกชั้นเหนือ Local permission
เมื่อพบ Permission denied ให้เริ่มจาก Subject + Operation + Resolved path + Policy + Evidence ตรวจ Parent directory และตัวตนจริง เปลี่ยนกติกาทีละจุดตาม Least privilege แล้วทดสอบ Workflow เดิมพร้อมผลข้างเคียง วิธีนี้ช้ากว่าคำสั่งเปิดกว้างหนึ่งบรรทัดเพียงเล็กน้อย แต่ให้คำตอบที่ตรวจสอบ ย้อนกลับ และใช้ซ้ำได้
SUMMARY INFOGRAPHIC
ภาพสรุป: จาก User และ Process ผ่าน Path สู่ Permission gate
เรียนต่ออย่างมีทิศทาง
นำ Access Journey Card ไปวิเคราะห์โฟลเดอร์จริงหนึ่งตำแหน่งโดยไม่เปลี่ยนสิทธิ์ก่อน ระบุ Subject, Operation, Resolved path และ Parent directory ให้ครบ แล้วกลับไปดู Learning Pack PATH 01 เพื่อเชื่อมบทเรียนนี้กับระบบปฏิบัติการและพื้นฐานเครือข่ายในหัวข้อถัดไป
ดู Learning Pack PATH 01 ทั้งชุด →แหล่งอ้างอิงและบันทึกบรรณาธิการ
- Microsoft Learn — File Security and Access Rights — Security descriptor, ACL, Access token และสิทธิ์สำหรับ File/Directory
- Microsoft Learn — Access Control Overview — Permission, Ownership, Inheritance และ Effective access บน Windows
- Microsoft Learn — Naming Files, Paths, and Namespaces — Path, Drive, UNC, Relative path และกฎชื่อไฟล์
- Apple Support — Change permissions for files, folders, or disks on Mac — Read & Write, Read only, Write only, No Access และ Owner
- Apple Support — Control access to files and folders on Mac — App privacy สำหรับ Documents, Desktop และ Downloads
- Linux Kernel Documentation — Virtual File System — Dentry, Inode, File object และ File descriptor
- Linux man-pages — path_resolution(7) — ขั้นตอน Resolve Path และ Permission ระหว่างทาง
- Linux man-pages — symlink(7) — Symbolic link, Traversal และข้อควรระวัง
- The Open Group Base Specifications — General Concepts — Owner, Group, Other และ Read/Write/Execute/Search permission
- Microsoft Support — See who a file is shared with — Direct, Group และ Link access บน OneDrive/SharePoint
ขอบเขต: รายละเอียด Permission, ACL, Link, Copy/Move, Timestamp และ Sandbox แตกต่างตาม OS, File System, App และเวอร์ชัน บทเรียนนี้สร้างแบบจำลองร่วมเพื่อใช้วิเคราะห์ ไม่แทนเอกสารเฉพาะระบบหรือ Policy ขององค์กร
ตรวจข้อเท็จจริงและทบทวนภาษาไทย: 11 สิงหาคม 2026 · AI Encyclopedia หัวข้อ 37 · PATH 01
