Permission និង sudo

មាតិកា

  1. អ្នកណាអាចធ្វើអ្វីបាន
  2. ការអាន Permission ក្នុង ls -l
  3. តើ r, w និង x មានន័យអ្វីសម្រាប់ File និង Folder
  4. ការផ្លាស់ប្តូរ Permission៖ chmod
  5. Permission ជាលេខ៖ 755, 644, 600
  6. ការរត់ Script ផ្ទាល់ខ្លួន៖ ហេតុអ្វីត្រូវការ ./ និង +x
  7. ក្លាយជាអ្នកគ្រប់គ្រង៖ sudo
  8. ពេលណាមិនគួរប្រើ sudo
  9. សាកល្បងដោយខ្លួនឯង

1. អ្នកណាអាចធ្វើអ្វីបាន

នៅក្នុង File និង File System អ្នកបានឃើញថា គ្រប់ file លើ macOS និង Linux មាន ម្ចាស់ (owner) និងសំណុំ permission មួយ ហើយថា Permission denied គឺជាប្រព័ន្ធប្រតិបត្តិការកំពុងអនុវត្តពួកវា។ ជំពូកនេះជាកន្លែងដែលអ្នករៀនអាន permission ទាំងនោះ និងផ្លាស់ប្តូរពួកវា។

ហេតុអ្វីរឿងនេះសំខាន់ បើអ្នកជាមនុស្សតែម្នាក់គត់ដែលប្រើ laptop របស់អ្នក?

  • កុំព្យូទ័ររបស់អ្នកមាន «អ្នកប្រើប្រាស់ (user)» ជាច្រើនដែលអ្នកមិនដែលឃើញ។ Service ប្រព័ន្ធ database និង web server នីមួយៗរត់ជា user ផ្ទាល់ខ្លួន ដូច្នេះ bug នៅក្នុងមួយមិនអាចប៉ះពាល់ file របស់មួយផ្សេងទៀតបានទេ។
  • Server ត្រូវបានប្រើរួមគ្នា។ នៅពេលអ្នក deploy កម្មវិធីមួយទៅ Linux server កម្មវិធី web server និងអ្នក សុទ្ធតែជា user ផ្សេងៗគ្នា ហើយការកំណត់ permission ឲ្យត្រឹមត្រូវ គឺជាផ្នែកមួយនៃការរក្សាវាឲ្យមានសុវត្ថិភាព។
  • Script ត្រូវការ permission ដើម្បីរត់។ អ្នកនឹងជួបរឿងនេះនៅក្នុងជំពូកនេះតែម្តង។
cd ~/cli-practice

Git Bash៖ Windows រក្សាទុក permission ខុសពីនេះ ដូច្នេះ chmod មានឥទ្ធិពលតិចតួចនៅទីនោះ ហើយ sudo មិនមានទេ។ អានតាមទៅចុះ — អ្នកនឹងត្រូវការអ្វីៗទាំងអស់នេះលើ server និងក្នុង Docker container — ហើយប្រើ WSL បើអ្នកចង់សាកគ្រប់លំហាត់។

2. ការអាន Permission ក្នុង ls -l

កាលពីជំពូកទី 3 អ្នកបានរំលងផ្នែកមួយនៃលទ្ធផល ls -l។ ឥឡូវតោះអានវា៖

ls -l notes/shopping.txt
-rw-r--r--  1 dara  staff  29 Oct  1 10:15 notes/shopping.txt

ប្លុកទីមួយ -rw-r--r-- មានដប់តួអក្សរ។ តួទីមួយគឺ ប្រភេទ (- សម្រាប់ file, d សម្រាប់ folder)។ ប្រាំបួនតួទៀតគឺបីក្រុម ក្រុមនីមួយៗមានបីតួ៖

 -    rw-     r--     r--
type  owner   group   others
  • owner (ហៅផងដែរថា user, u) — user ដែលជាម្ចាស់ file៖ dara
  • group (g) — ក្រុម user ដែលចែករំលែកសិទ្ធិចូលប្រើ៖ staff
  • others (o) — អ្នកផ្សេងទៀតទាំងអស់លើកុំព្យូទ័រ

នៅក្នុងក្រុមនីមួយៗ ទីតាំងទាំងបីតែងតែជា r, w, x តាមលំដាប់នោះ។ អក្សរមួយមានន័យថា permission ត្រូវបានផ្តល់ឲ្យ ចំណែក - មានន័យថាមិនបានផ្តល់ឲ្យទេ។ ដូច្នេះ -rw-r--r-- អានថា៖ «ជា file មួយ ម្ចាស់អាចអាន និងសរសេរវាបាន group អាចត្រឹមតែអានវា អ្នកផ្សេងទៀតទាំងអស់អាចត្រឹមតែអានវា»។

នោះជា permission ដែលឃើញញឹកញាប់បំផុតសម្រាប់ file ធម្មតា។

លើ macOS អ្នកប្រហែលជាឃើញ @ ឬ + បន្ថែមភ្លាមៗក្រោយ permission ដូចជា -rw-r--r--@។ នោះគ្រាន់តែមានន័យថា file មាន metadata បន្ថែមភ្ជាប់មកជាមួយ។ អ្នកអាចមិនអើពើវាបាន។

3. តើ r, w និង x មានន័យអ្វីសម្រាប់ File និង Folder

អក្សរទាំងនេះមានន័យខុសគ្នាបន្តិចសម្រាប់ file និង folder៖

សម្រាប់ fileសម្រាប់ folder
r (read)អានខ្លឹមសាររបស់វាបង្ហាញបញ្ជីអ្វីដែលនៅខាងក្នុង (ls)
w (write)ផ្លាស់ប្តូរខ្លឹមសាររបស់វាបង្កើត ប្តូរឈ្មោះ ឬលុប file នៅខាងក្នុងវា
x (execute)រត់វាជាកម្មវិធីចូលទៅក្នុងវា (cd) និងចូលដល់ file នៅខាងក្នុង

មានពីរក្នុងចំណោមនេះដែលធ្វើឲ្យមនុស្សភ្ញាក់ផ្អើល៖

  • ការលុប file អាស្រ័យលើ folder មិនមែនលើ file ទេ។ ការលុប file មួយផ្លាស់ប្តូរបញ្ជីខ្លឹមសាររបស់ folder ដូច្នេះ w របស់ folder ទើបជាអ្វីដែលសំខាន់។
  • Folder ត្រូវការ x ទើបអាចប្រើបាន។ បើគ្មានវា អ្នកមិនអាច cd ចូលទៅក្នុង folder ឬបើកអ្វីនៅខាងក្នុងបានទេ ទោះបីអ្នកដឹងឈ្មោះក៏ដោយ។ នោះហើយជាមូលហេតុដែល folder ស្ទើរតែតែងតែមាន x នៅគ្រប់កន្លែងដែលវាមាន r៖ drwxr-xr-x។

4. ការផ្លាស់ប្តូរ Permission៖ chmod

chmod (change mode) ផ្លាស់ប្តូរ permission។ វិធីងាយស្រួលបំផុតក្នុងការប្រើវាគឺជាមួយអក្សរ៖ អ្នកណា បន្ទាប់មក + (បន្ថែម) ឬ - (ដកចេញ) បន្ទាប់មក permission មួយណា៖

chmod u+x file      # owner: add execute
chmod g-w file      # group: remove write
chmod o-r file      # others: remove read
chmod go-rw file    # group and others: remove read and write
chmod +x file       # add execute for everyone

តោះមើលវាដំណើរការជាក់ស្តែង។ បង្កើត file មួយ ហើយដក permission អានរបស់អ្នកផ្ទាល់ចេញ៖

echo "top secret" > notes/secret.txt
chmod u-r notes/secret.txt
cat notes/secret.txt
cat: notes/secret.txt: Permission denied

អ្នកជាម្ចាស់ file ប៉ុន្តែអ្នកបានប្រាប់ OS មិនឲ្យសូម្បីតែអ្នកអានវា។ ផ្តល់វាត្រឡប់មកវិញ៖

chmod u+r notes/secret.txt
cat notes/secret.txt

អ្នកអាចផ្លាស់ប្តូរ permission បានតែលើ file ដែល អ្នកជាម្ចាស់ ប៉ុណ្ណោះ (ឬក្នុងនាមជាអ្នកគ្រប់គ្រង ក្នុងផ្នែកទី 7)។

5. Permission ជាលេខ៖ 755, 644, 600

នៅក្នុង tutorial និងឯកសារ អ្នកនឹងឃើញជាញឹកញាប់នូវ permission ដែលសរសេរជា លេខបីខ្ទង់ ដូចជា chmod 755 ឬ chmod 600។ លេខនីមួយៗគឺជាក្រុមមួយ — owner, group, others — ហើយត្រូវបានបង្កើតឡើងដោយការបូក៖

Permissionតម្លៃ
r4
w2
x1

ដូច្នេះ 7 = 4 + 2 + 1 = rwx, 6 = 4 + 2 = rw-, 5 = 4 + 1 = r-x, 4 = r-- និង 0 = ---។

អ្នកនឹងជួបបន្សំមួយចំនួនដដែលៗម្តងហើយម្តងទៀត៖

លេខអក្សរប្រើសម្រាប់
644rw-r--r--File ធម្មតា
755rwxr-xr-xScript កម្មវិធី និង folder
600rw-------File ឯកជន៖ SSH key, file .env ដែលមានព័ត៌មានសម្ងាត់
700rwx------Folder ឯកជន ដូចជា ~/.ssh
chmod 600 notes/secret.txt
ls -l notes/secret.txt
-rw-------  1 dara  staff  11 Oct  1 11:02 notes/secret.txt

ឥឡូវមានតែអ្នកប៉ុណ្ណោះដែលអាចអាន ឬសរសេរវាបាន។ SSH ពិតជានឹង បដិសេធ មិនប្រើ private key ដែល user ផ្សេងទៀតអាចអានបាន — ដែលជា error permission ដំបូងៗមួយដែលអ្នកនឹងជួបនៅពេល deploy ទៅ server។

កុំដែល chmod 777។ វាមានន័យថា «គ្រប់គ្នាអាចអាន ផ្លាស់ប្តូរ និងរត់វាបាន»។ Tutorial ខ្លះណែនាំវាដើម្បីធ្វើឲ្យ error Permission denied បាត់ទៅ ហើយវាពិតជាបាត់មែន — ដោយការដកការការពារទាំងអស់ចេញ។ ផ្ទុយទៅវិញ សូមរកឲ្យឃើញថា អ្នកណា ដែលត្រូវការសិទ្ធិចូលប្រើ។

6. ការរត់ Script ផ្ទាល់ខ្លួន៖ ហេតុអ្វីត្រូវការ ./ និង +x

Shell script គឺជា text file ដែលពោរពេញដោយ command។ តោះបង្កើតមួយតូចៗ (ជំពូកទី 11 ពន្យល់អំពីបន្ទាត់ទីមួយ)៖

printf '%s\n' '#!/bin/bash' 'echo "Hello from my first script!"' > hello.sh

សាករត់វាតាមរបៀបដែលអ្នករត់ command ណាមួយ៖

hello.sh
zsh: command not found: hello.sh

ចាំជំពូកទី 9៖ shell ស្វែងរក command តែនៅក្នុង folder ដែលមានលើ PATH របស់អ្នកប៉ុណ្ណោះ ហើយ folder បច្ចុប្បន្នមិនមែនជាផ្នែកមួយក្នុងចំណោមនោះទេ។ នោះជាចេតនា — បើមិនដូច្នោះទេ file ព្យាបាទមួយដែលមានឈ្មោះ ls ដែលនៅក្នុង folder ដែលបាន download មក អាចរត់ជំនួស ls ពិតប្រាកដ។ ដើម្បីរត់កម្មវិធីមួយនៅក្នុង folder បច្ចុប្បន្ន សូមផ្តល់ path របស់វា៖ ./ មានន័យថា «នៅក្នុង folder នេះ» (ជំពូកទី 3)។

./hello.sh
zsh: permission denied: ./hello.sh

មានការរីកចម្រើន ប៉ុន្តែឥឡូវ OS បដិសេធ។ មើល permission៖

ls -l hello.sh
-rw-r--r--  1 dara  staff  47 Oct  1 11:10 hello.sh

គ្មាន x នៅកន្លែងណាសោះ។ File ថ្មីមិនដែលអាច execute បានតាមលំនាំដើមទេ — នេះជាលក្ខណៈសុវត្ថិភាពមួយទៀត។ បន្ថែមវា៖

chmod +x hello.sh
./hello.sh
Hello from my first script!

ត្រូវការទាំងពីរ៖ ./ ដើម្បីឲ្យ shell អាច រកឃើញ វា និង +x ដើម្បីឲ្យ OS រត់ វា។ នេះពិតជា error Permission denied ពីជំពូកទី 2 មែន។

អ្នកក៏អាចរំលង permission x បានដែរ ដោយបញ្ជូន file ទៅ Bash ដោយខ្លួនឯង ព្រោះ Bash ត្រូវការត្រឹមតែ អាន វាប៉ុណ្ណោះ៖

bash hello.sh

7. ក្លាយជាអ្នកគ្រប់គ្រង៖ sudo

File មួយចំនួនជារបស់ប្រព័ន្ធ មិនមែនរបស់អ្នកទេ។ សាកសរសេរចូលទៅក្នុង folder ប្រព័ន្ធ /etc៖

touch /etc/test-file
touch: /etc/test-file: Permission denied

File ទាំងនេះជាកម្មសិទ្ធិរបស់ root ដែលជា user អ្នកគ្រប់គ្រង ដែលអាចធ្វើអ្វីក៏បានលើប្រព័ន្ធ។ នៅពេលអ្នកពិតជាត្រូវការផ្លាស់ប្តូរអ្វីមួយទូទាំងប្រព័ន្ធ — ញឹកញាប់បំផុតគឺ ការដំឡើង software — អ្នកប្រើ sudo (superuser do) ដើម្បីរត់ command មួយ ជា root៖

sudo apt update             # Ubuntu and WSL: refresh the list of packages
sudo apt install tree       # install a program called tree

sudo សុំ ពាក្យសម្ងាត់ផ្ទាល់ខ្លួនរបស់អ្នក (មិនមែនពាក្យសម្ងាត់ root ដាច់ដោយឡែកទេ — លើ WSL វាគឺជាពាក្យសម្ងាត់ Linux ដែលអ្នកបានជ្រើសរើសពេលរៀបចំ) ហើយដូចពេលអ្នករៀបចំ WSL ដែរ គ្មានអ្វីលេចឡើងលើអេក្រង់ពេលអ្នកវាយទេ។ វាចងចាំបានពីរបីនាទី ដូច្នេះ sudo បន្ទាប់នឹងមិនសួរម្តងទៀតទេ។

លើ macOS អ្នកកម្រត្រូវការ sudo សម្រាប់ដំឡើង software ណាស់៖ package manager Homebrew (brew install tree) ត្រូវបានរចនាឡើងឲ្យដំណើរការដោយមិនចាំបាច់ប្រើវា។

សាកកម្មវិធីថ្មី៖

tree ~/cli-practice

វាគូរ folder អនុវត្តរបស់អ្នកជាមែកធាង — ដូចដ្យាក្រាមក្នុង File និង File System។

បើអ្នកធ្លាប់ឃើញ prompt ដែលបញ្ចប់ដោយ # ជំនួសឲ្យ $ នោះអ្នកកំពុង login ជា root (ជំពូកទី 1)។ គ្រប់ command រត់ជាមួយអំណាចពេញលេញ ដូច្នេះត្រូវប្រុងប្រយ័ត្នបន្ថែម — ហើយវាយ exit នៅពេលអ្នកធ្វើរួច។

8. ពេលណាមិនគួរប្រើ sudo

sudo បិទរបាំងសុវត្ថិភាព ដូច្នេះច្បាប់គឺ៖ ប្រើវាតែនៅពេលអ្នកដឹងថាហេតុអ្វី command មួយត្រូវការ root ប៉ុណ្ណោះ។ «ខ្ញុំទទួលបាន Permission denied ដូច្នេះខ្ញុំបន្ថែម sudo» គឺជាទម្លាប់មួយដែលបង្កបញ្ហាពិតប្រាកដ៖

  • កុំដែលប្រើ sudo នៅក្នុង project ផ្ទាល់ខ្លួនរបស់អ្នក។ បើ sudo npm install ឬ sudo git pull បង្កើត file នៅក្នុង project របស់អ្នក file ទាំងនោះឥឡូវជាកម្មសិទ្ធិរបស់ root ហើយ user ធម្មតារបស់អ្នកនឹងទទួលបាន Permission denied លើវារហូតតទៅ។
  • កុំ sudo npm install -g។ ការដំឡើងឧបករណ៍ Node.js សកល (global) ដោយ sudo គឺជាប្រភពបុរាណនៃការឈឺក្បាលពី permission។ ប្រើ Node version manager ដូចជា nvm ដែលដំឡើងអ្វីៗទាំងអស់នៅខាងក្នុង home folder របស់អ្នក ដូច្នេះមិនដែលត្រូវការ sudo ឡើយ។
  • កុំដែល sudo command ដែលអ្នកចម្លងមក ប៉ុន្តែមិនយល់។ rm -rf ជាមួយ sudo អាចលុបប្រព័ន្ធប្រតិបត្តិការខ្លួនវាផ្ទាល់បាន។

បើអ្នកបានជួបស្ថានភាពដែលមាន file ជាកម្មសិទ្ធិរបស់ root នៅខាងក្នុង home folder របស់អ្នករួចហើយ chown (change owner) ប្រគល់វាត្រឡប់មកអ្នកវិញ៖

sudo chown -R $USER ~/cli-practice

-R មានន័យថា recursive — folder និងអ្វីៗទាំងអស់នៅខាងក្នុងវា — ហើយ $USER គឺជាឈ្មោះអ្នកប្រើប្រាស់របស់អ្នក (ជំពូកទី 9)។ នេះជាករណីកម្រមួយដែល sudo ពិតជា ឧបករណ៍ត្រឹមត្រូវ៖ មានតែ root ទេដែលអាចផ្លាស់ប្តូរម្ចាស់របស់ file បាន។

9. សាកល្បងដោយខ្លួនឯង

ធ្វើការនៅខាងក្នុង ~/cli-practice។

  1. រត់ ls -l ក្នុង notes និង ls -ld notes (-d បង្ហាញ folder ខ្លួនវាផ្ទាល់ មិនមែនខ្លឹមសាររបស់វាទេ)។ អាន permission ឲ្យឮៗ៖ តើអ្នកណាអាចធ្វើអ្វីបាន?
  2. បង្កើត notes/private.txt បន្ទាប់មកប្រើ chmod ជាមួយ អក្សរ ដើម្បីដក permission ទាំងអស់ចេញសម្រាប់ group និង others។ ពិនិត្យដោយ ls -l។
  3. ធ្វើដូចគ្នាទៅនឹង file ទីពីរ ដោយប្រើ លេខ។ តើអ្នកបានប្រើលេខអ្វី?
  4. បង្កើត folder locked រត់ chmod 000 locked ហើយសាក ls locked និង cd locked។ បន្ទាប់មកស្តារវាវិញដោយ chmod 755 locked។
  5. បង្កើត script ផ្ទាល់ខ្លួន greet.sh ដែលរត់ echo និង date។ សាករត់វាដោយ greet.sh បន្ទាប់មក ./greet.sh បន្ទាប់មកកែវាដោយ chmod +x ហើយរត់វាឲ្យជោគជ័យ។
  6. លើ Ubuntu ឬ WSL ដំឡើង tree ដោយ sudo apt install tree (ឬ brew install tree លើ macOS ជាមួយ Homebrew) ហើយរត់ tree លើ folder អនុវត្តរបស់អ្នក។

ឥឡូវអ្នកដឹងហើយថាហេតុអ្វី Permission denied កើតឡើង និងរបៀបដោះស្រាយវាឲ្យបានត្រឹមត្រូវ។ នៅក្នុងជំពូកចុងក្រោយ តោះដាក់អ្វីៗទាំងអស់បញ្ចូលគ្នា ហើយសរសេរ shell script ពិតប្រាកដមួយ។

ទិញកាហ្វេជូនខ្ញុំ

ចូលចិត្តមេរៀននេះមែនទេ? សូមពិចារណាទិញកាហ្វេជូនខ្ញុំមួយកែវ ដើម្បីគាំទ្រការបង្កើតមាតិកាឥតគិតថ្លៃបន្ថែមទៀត!