เข้าใจ Linux Permission บน Ubuntu: ใช้ chmod, chown และ sudo ให้ปลอดภัย

หลายคนที่เริ่มใช้ Ubuntu หรือ Linux ใหม่ ๆ มักเจอข้อความ Permission denied แล้วแก้ปัญหาแบบทันทีด้วยการเติม sudo หน้าทุกคำสั่ง หรือเปลี่ยนสิทธิ์เป็น 777 เพื่อให้ใช้งานต่อได้ก่อน

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

หัวใจสำคัญของ Linux Permission คือระบบไม่ได้ถามแค่ว่า “ไฟล์นี้เปิดได้ไหม” แต่ถามว่า “ใครกำลังพยายามทำอะไรกับไฟล์หรือโฟลเดอร์นี้” หากเข้าใจแนวคิดนี้ เราจะสามารถแก้ปัญหา Permission denied ได้อย่างถูกต้องมากขึ้น

โครงสร้างสิทธิ์ของไฟล์ใน Linux

ทุกไฟล์และโฟลเดอร์ใน Linux จะมีผู้เกี่ยวข้องหลัก 3 กลุ่ม

• owner คือเจ้าของไฟล์
• group คือกลุ่มผู้ใช้ที่ได้รับสิทธิ์ร่วมกัน
• other คือผู้ใช้อื่นทั้งหมดในระบบ

สิทธิ์พื้นฐานมี 3 แบบ ได้แก่

• r = read อ่านไฟล์ หรือดูรายชื่อไฟล์ในโฟลเดอร์
• w = write แก้ไขไฟล์ สร้าง ลบ หรือเปลี่ยนชื่อรายการในโฟลเดอร์
• x = execute รันไฟล์เป็นโปรแกรม หรือเข้าใช้งานภายในโฟลเดอร์

สิทธิ์เหล่านี้ทำให้ระบบสามารถแยกได้ว่า ใครควรอ่าน ใครควรแก้ และใครควรรันไฟล์นั้นได้

ดู Permission ด้วย ls -l

คำสั่งพื้นฐานที่ควรรู้คือ

ls -l

ตัวอย่างผลลัพธ์

-rw-r--r-- 1 olan dev 1200 Jul 12 app.conf

ส่วนแรก -rw-r--r-- คือข้อมูลสิทธิ์ของไฟล์ โดยอ่านจากซ้ายไปขวา

• ตัวแรก - หมายถึงไฟล์ปกติ
• ถ้าเป็น d หมายถึง directory
• rw- คือสิทธิ์ของ owner
• r-- คือสิทธิ์ของ group
• r-- คือสิทธิ์ของ other

จากตัวอย่างนี้ หมายความว่า

• เจ้าของไฟล์อ่านและเขียนได้
• คนในกลุ่มอ่านได้อย่างเดียว
• ผู้ใช้อื่นก็อ่านได้อย่างเดียว

หากไฟล์นี้เป็นไฟล์สำคัญ เช่นไฟล์ config ที่มี secret, environment variables หรือ private key การเปิดให้อ่านได้ทุกคนถือว่าไม่เหมาะสมและควรรีบตรวจสอบ

chmod คือการเปลี่ยนสิทธิ์

chmod ใช้สำหรับเปลี่ยน permission ของไฟล์หรือโฟลเดอร์ โดย ไม่เปลี่ยนเจ้าของไฟล์

สำหรับมือใหม่ รูปแบบตัวอักษรจะเข้าใจง่ายที่สุด เช่น

chmod u+x deploy.sh

คำสั่งนี้หมายถึง เพิ่มสิทธิ์ execute ให้กับ user หรือเจ้าของไฟล์

อีกตัวอย่างหนึ่ง

chmod g-w app.conf

หมายถึง เอาสิทธิ์เขียนของ group ออกจากไฟล์ app.conf

การใช้ chmod แบบตัวเลข

รูปแบบตัวเลขเป็นสิ่งที่พบได้บ่อย เช่น

chmod 644 app.conf
chmod 755 deploy.sh

เลขแต่ละหลักแทนสิทธิ์ของ

1. owner
2. group
3. other

โดยค่าของสิทธิ์คือ

• r = 4
• w = 2
• x = 1

เมื่อนำมาบวกกันจะได้เป็นตัวเลข เช่น

• 6 = 4 + 2 = read + write
• 7 = 4 + 2 + 1 = read + write + execute
• 5 = 4 + 1 = read + execute
• 4 = read อย่างเดียว

ดังนั้น

• 644 เหมาะกับไฟล์ทั่วไป: เจ้าของอ่านเขียนได้ ส่วนคนอื่นอ่านได้
• 755 มักเหมาะกับสคริปต์หรือโฟลเดอร์: เจ้าของจัดการได้ และคนอื่นเข้าถึงหรือรันได้ตามจำเป็น

ทำไมไม่ควรใช้ 777 เป็นทางลัด

หลายคนจำว่าเมื่อเจอ Permission denied ให้ใช้

chmod 777 somefile

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

777 จึงไม่ควรถูกใช้เป็นคำตอบมาตรฐานของทุกปัญหา

สิทธิ์ของโฟลเดอร์สำคัญไม่แพ้ไฟล์

เวลาตรวจปัญหา Permission denied หลายคนมองเฉพาะไฟล์เป้าหมาย แต่ลืมว่า โฟลเดอร์แม่ก็มีผลต่อการเข้าถึง

แม้ไฟล์จะมีสิทธิ์อ่านได้ แต่ถ้าโฟลเดอร์ที่ครอบอยู่ไม่มี x ผู้ใช้ก็อาจไม่สามารถเข้าไปถึงไฟล์นั้นได้อยู่ดี

ดังนั้นหากมีปัญหากับไฟล์ในโปรเจกต์ ควรตรวจทั้ง

• สิทธิ์ของไฟล์
• สิทธิ์ของโฟลเดอร์ที่เก็บไฟล์
• เจ้าของและกลุ่มของทั้งสองส่วน

chown คือการเปลี่ยนเจ้าของไฟล์

chown ใช้เปลี่ยน owner และสามารถเปลี่ยน group ได้ด้วย

ตัวอย่าง

sudo chown olan app.conf
sudo chown olan:dev app.conf

ความหมายคือ

• คำสั่งแรก เปลี่ยนเจ้าของไฟล์เป็น olan
• คำสั่งที่สอง เปลี่ยนเจ้าของเป็น olan และเปลี่ยนกลุ่มเป็น dev

กรณีที่พบได้บ่อยคือ เคยใช้ sudo สร้างไฟล์ในโปรเจกต์ ทำให้ไฟล์นั้นกลายเป็นของ root จากนั้นเมื่อกลับมาเปิดด้วย editor ปกติจะแก้ไม่ได้

ทางแก้ที่ดีกว่า ไม่ใช่การเปิด editor ด้วย sudo ทุกครั้ง แต่คือการ คืนเจ้าของไฟล์หรือโฟลเดอร์ให้ถูกต้อง

ตัวอย่าง

sudo chown -R olan:dev /home/olan/project

ตัวเลือก -R หมายถึงเปลี่ยนแบบ recursive ครอบคลุมทุกไฟล์และโฟลเดอร์ย่อย จึงต้องใช้อย่างระมัดระวังมาก

ก่อนรันคำสั่งลักษณะนี้ ควรตรวจสอบเสมอด้วย

pwd
ls

และไม่ควรนำคำสั่งแบบนี้ไปใช้กับ path สำคัญ เช่น

• /
• /etc
• /usr
• home directory ของผู้ใช้อื่น

เพราะอาจทำให้ระบบเสียหายได้

sudo คือการยกระดับสิทธิ์ ไม่ใช่คำตอบของทุกปัญหา

หลายคนเข้าใจว่า sudo คือคำสั่งสำหรับแก้ปัญหา permission แต่จริง ๆ แล้ว sudo หมายถึงการรันคำสั่งด้วยสิทธิ์ของผู้ดูแลระบบหรือ root

ควรใช้เมื่อทำงานที่จำเป็นต้องมีสิทธิ์ระดับระบบจริง ๆ เช่น

• ติดตั้งแพ็กเกจ
• แก้ไฟล์ตั้งค่าระบบ
• จัดการ service
• ทำงานด้าน administration ของระบบ

ก่อนกด Enter หลังใช้ sudo ควรถามตัวเอง 3 ข้อ

1. คำสั่งนี้กำลังแก้อะไร
2. ไฟล์หรือโฟลเดอร์ปลายทางอยู่ที่ไหน
3. จำเป็นต้องเป็น root จริงไหม

ถ้าคำตอบยังไม่ชัด ควรหยุดตรวจสอบก่อนเสมอ

แนวทางปลอดภัยสำหรับมือใหม่

หากต้องการลดความเสี่ยงในการพังระบบหรือเปิดสิทธิ์เกินจำเป็น ควรยึดแนวทางดังนี้

• ใช้ ls -l ตรวจสิทธิ์ก่อนแก้
• ใช้ whoami ดูว่าตอนนี้กำลังทำงานในฐานะผู้ใช้ใด
• ใช้ pwd ยืนยันตำแหน่งปัจจุบันก่อนรันคำสั่งที่มี -R
• เปลี่ยนสิทธิ์ให้แคบที่สุดเท่าที่จำเป็น
• ใช้ sudo เฉพาะคำสั่งที่ต้องใช้จริง ไม่ใช่ใช้พร่ำเพรื่อกับทุกคำสั่ง

แนวคิดนี้จะช่วยให้เราแก้ปัญหาได้อย่างมีเหตุผล และลดโอกาสสร้างปัญหาใหม่โดยไม่ตั้งใจ

สรุป

การเข้าใจ Linux Permission อย่างถูกต้อง ช่วยให้จัดการไฟล์และโฟลเดอร์บน Ubuntu ได้ปลอดภัยมากขึ้น

• chmod ใช้เปลี่ยนสิทธิ์
• chown ใช้เปลี่ยนเจ้าของหรือกลุ่ม
• sudo ใช้ยกระดับสิทธิ์ชั่วคราว

เมื่อรู้หน้าที่ของแต่ละคำสั่ง เราจะไม่ต้องพึ่ง chmod 777 เป็นทางลัด และไม่จำเป็นต้องเติม sudo หน้าทุกอย่างแบบเสี่ยง ๆ อีกต่อไป การแก้ Permission denied ที่ดีคือการดูให้ชัดว่าใครกำลังพยายามทำอะไรกับไฟล์ใด แล้วปรับสิทธิ์เท่าที่จำเป็นเท่านั้น