1. Mục tiêu

Trong Linux, không phải user nào cũng có quyền làm mọi thứ.

Ví dụ:

developer → đọc source code
deploy    → chạy application
admin     → quản trị server

Linux kiểm soát quyền dựa trên:

User
  ↓
Group
  ↓
Permission
  ↓
File / Directory

Sau lab này, bạn có thể:

• Hiểu user, group, root.
• Hiểu r, w, x.
• Sử dụng chmod, chown, chgrp.
• Hiểu permission dạng 755, 644.
• Biết cách sử dụng sudo.
• Thiết lập quyền cho một application directory.
• Debug lỗi Permission denied.

---

2. User trong Linux

Kiểm tra user hiện tại:

whoami

Xem thông tin user:

id

Ví dụ:

uid=1000(devops) gid=1000(devops) groups=1000(devops),27(sudo)

Trong đó:

uid    → User ID
gid    → Group ID
groups → Các group user đang thuộc về

Xem các user:

cat /etc/passwd

Lưu ý: /etc/passwd chứa thông tin account, nhưng không chứa password dạng plaintext.

---

3. Root User

root là user có quyền quản trị cao nhất.

Kiểm tra:

whoami

Nếu kết quả:

root

thì bạn đang sử dụng root.

Trong thực tế, không nên chạy mọi thứ bằng root.

Thay vào đó:

sudo command

Ví dụ:

sudo apt update

Tư duy nên là:

Normal user
    ↓
Cần quyền đặc biệt?
    ↓
  sudo
    ↓
Execute command

Kinh nghiệm thực tế

Nếu một application có thể chạy bằng user bình thường thì không nên chạy application bằng root.

Nếu application bị hack, attacker sẽ có ít quyền hơn.

Đây là một nguyên tắc bảo mật rất quan trọng:

Run with the least privilege necessary.

---

4. Tạo User

Tạo user:

sudo useradd -m developer

Đặt password:

sudo passwd developer

Kiểm tra:

id developer

Chuyển sang user:

su - developer

Quay lại user trước:

exit

Tip: Trong môi trường server thực tế, thường tạo user riêng cho từng mục đích như deploy, jenkins, ansible thay vì dùng chung một tài khoản.

---

5. Group

Group giúp quản lý quyền cho nhiều user cùng lúc.

Tạo group:

sudo groupadd developers

Thêm user vào group:

sudo usermod -aG developers developer

Kiểm tra:

groups developer

Có thể hiểu:

developers
    │
    ├── alice
    ├── bob
    └── developer

Thay vì cấp quyền cho từng user, ta cấp quyền cho group.

Đây là cách quản lý rất phổ biến trong Linux server.

---

6. File Ownership

Tạo file:

touch app.log

Xem thông tin:

ls -l app.log

Ví dụ:

-rw-r--r-- 1 devops devops 0 Aug 10 10:00 app.log

Phần quan trọng:

-rw-r--r--
      │   │
      │   └── Others
      └────── Group

Cụ thể:

-rw-r--r--
 │  │   │
 │  │   └── Others
 │  └────── Group
 └───────── Owner

Owner:

devops

Group:

devops

---

7. Permission r, w, x

Linux có 3 quyền cơ bản:

r → read
w → write
x → execute

Với file:

r → đọc file
w → sửa file
x → chạy file

Ví dụ:

-rwxr-xr--

Chia thành:

Owner   Group   Others
rwx     r-x     r--

Có nghĩa:

Owner  → read + write + execute
Group  → read + execute
Others → read

---

8. Permission trên Directory

Đây là phần người mới thường dễ nhầm.

Với directory:

r → xem danh sách file
w → tạo/xóa file
x → truy cập directory

Ví dụ:

drwxr-x---

Có nghĩa:

Owner → đọc + ghi + truy cập
Group → đọc + truy cập
Others → không có quyền

Điểm quan trọng

Quyền x trên directory rất quan trọng.

Bạn có thể có:

r

nhưng không có:

x

thì vẫn không thể truy cập file bên trong directory theo cách thông thường.

---

9. chmod

chmod dùng để thay đổi permission.

Ví dụ:

chmod 755 script.sh

Hiểu 755:

7 → Owner
5 → Group
5 → Others

Giá trị:

r = 4
w = 2
x = 1

Do đó:

7 = 4 + 2 + 1 = rwx
5 = 4 + 1     = r-x
4 = 4         = r--

Vậy 755 tương đương rwxr-xr-x

---

10. Một số Permission thường gặp

Permission	Ý nghĩa
600	Owner đọc/ghi
644	Owner đọc/ghi, còn lại đọc
700	Chỉ owner toàn quyền
755	Owner toàn quyền, còn lại đọc/chạy
775	Owner/group toàn quyền
777	Tất cả toàn quyền

Trong thực tế:

File config      → thường 600/644
Script           → thường 755
Application dir  → thường 755/775
Private key      → thường 600

⚠️ Tránh dùng chmod 777 để "sửa lỗi Permission denied". Nó thường chỉ che giấu vấn đề permission và tạo ra rủi ro bảo mật.

---

11. chown

chown thay đổi owner.

Ví dụ:

sudo chown developer app.log

Thay đổi owner và group:

sudo chown developer:developers app.log

Kiểm tra:

ls -l app.log

---

12. chgrp

Thay đổi group:

sudo chgrp developers app.log

Có thể dùng:

sudo chown developer:developers app.log

để thay đổi cả hai.

---

13. Bài thực hành — Shared Application Directory

Bây giờ xây một tình huống giống thực tế.

Tạo:

/opt/todo-app

sudo mkdir -p /opt/todo-app

Tạo group:

sudo groupadd app

Tạo hai user:

sudo useradd -m developer
sudo useradd -m deploy

Thêm vào group:

sudo usermod -aG app developer
sudo usermod -aG app deploy

Đổi owner:

sudo chown -R root:app /opt/todo-app

Đặt permission:

sudo chmod -R 775 /opt/todo-app

Kiểm tra:

ls -ld /opt/todo-app

Kết quả mong muốn:

drwxrwxr-x root app /opt/todo-app

Bây giờ:

root
 │
 └── app group
       ├── developer
       └── deploy

Cả developer và deploy đều có thể làm việc trong directory.

---

14. Test Permission

Chuyển sang developer:

su - developer

Thử:

cd /opt/todo-app
touch test.txt

Nếu thành công:

Permission OK

Thoát:

exit

---

15. Thử tạo lỗi Permission Denied

Tạo file chỉ root được ghi:

sudo touch /opt/todo-app/secret.txt
sudo chown root:root /opt/todo-app/secret.txt
sudo chmod 600 /opt/todo-app/secret.txt

Chuyển sang:

su - developer

Thử:

echo "secret" > /opt/todo-app/secret.txt

Bạn sẽ nhận:

Permission denied

Đây là lỗi bạn sẽ gặp rất nhiều trong thực tế.

---

16. Cách Debug Permission denied

Đừng lập tức chạy:

chmod 777

Hãy kiểm tra theo thứ tự.

Bước 1 — Tôi đang là user nào?

whoami

Bước 2 — User thuộc group nào?

id

Bước 3 — File thuộc owner/group nào?

ls -l secret.txt

Bước 4 — Permission là gì?

-rw-------

Bước 5 — Kiểm tra directory cha

ls -ld /opt/todo-app

Nếu vẫn chưa rõ, dùng:

namei -l /opt/todo-app/secret.txt

Command này rất hữu ích để kiểm tra permission của từng directory trên đường dẫn.

Trick thực tế: Khi gặp Permission denied, namei -l thường giúp tìm ra vấn đề nhanh hơn việc nhìn mỗi ls -l của file.

---

17. sudo và /etc/sudoers

Kiểm tra user có sudo không:

sudo -l

Ví dụ:

User developer may run:
    (ALL) /usr/bin/systemctl restart todo-app

Điều này cho phép developer restart application nhưng không nhất thiết phải có toàn quyền server.

Đây là một ví dụ của Least Privilege.

⚠️ Không nên sửa trực tiếp /etc/sudoers bằng editor thông thường. Nếu cần thay đổi, sử dụng visudo để tránh lỗi syntax làm hỏng cấu hình sudo.

---

18. Bài tập tổng hợp

Hãy tự xây cấu trúc:

/opt/todo-app
├── app/
├── logs/
└── config/

Yêu cầu:

developer

Được:

app/    → read/write
logs/   → read
config/ → read

deploy

Được:

app/    → read/write
logs/   → read/write
config/ → read

root

Có toàn quyền.

Bạn cần sử dụng:

useradd
groupadd
usermod
chown
chmod

để giải quyết.

---

19. Một số kinh nghiệm thực tế

1. Không chạy application bằng root

Không nên:

root
 ↓
Application

Nên:

deploy
 ↓
Application

---

2. Không dùng 777 để sửa lỗi

Sai:

chmod -R 777 /opt/todo-app

Đúng hơn là xác định:

Ai cần truy cập?
        ↓
Cần quyền gì?
        ↓
Owner hay Group?
        ↓
chmod/chown phù hợp

---

3. Group tốt hơn cấp quyền từng user

Thay vì:

developer → permission
deploy → permission
jenkins → permission

nên:

app group
   ├── developer
   ├── deploy
   └── jenkins

Sau đó cấp quyền cho app.

---

4. Permission có thể ảnh hưởng Docker/Kubernetes

Đây là lý do kiến thức này rất quan trọng.

Ví dụ Docker container chạy với:

UID 1000

nhưng mounted volume thuộc:

root:root

Application có thể gặp:

Permission denied

Trong Kubernetes cũng tương tự khi Pod sử dụng:

Volume
SecurityContext
runAsUser
fsGroup

Nếu hiểu Linux permission từ bây giờ, các lỗi này sau này sẽ dễ debug hơn rất nhiều.

---

20. Checklist

Sau Lab 2, bạn nên tự trả lời được:

✓ User là gì?
✓ Group là gì?
✓ root là gì?
✓ sudo dùng để làm gì?
✓ UID/GID là gì?
✓ r/w/x nghĩa là gì?
✓ Permission 755 nghĩa là gì?
✓ Permission 644 nghĩa là gì?
✓ chmod dùng để làm gì?
✓ chown dùng để làm gì?
✓ chgrp dùng để làm gì?
✓ Vì sao không nên chmod 777?
✓ Làm thế nào debug Permission denied?
✓ Vì sao nên dùng Group?
✓ Least Privilege là gì?

Nếu bạn đã tự làm được bài Shared Application Directory và debug Permission denied mà không dùng chmod 777, thì bạn đã nắm được phần quan trọng nhất của Lab 2.

Lab tiếp theo: Lab 3 — Linux Process & Systemd sẽ bắt đầu đi vào một kỹ năng DevOps rất thực tế: application chạy thế nào, process được quản lý ra sao, service tự khởi động thế nào và debug application khi nó bị crash.