Vì sao chroot vẫn là “vũ khí” lợi hại sau hàng thập kỷ?
Nếu coi Docker là một căn hộ chung cư đầy đủ tiện nghi, thì chroot chính là những bức tường gạch thô sơ nhất. Xuất hiện từ năm 1979, chroot (change root) cho phép bạn thay đổi thư mục gốc ảo cho một tiến trình. Khi bị “nhốt” vào đây, ứng dụng sẽ coi thư mục đó là toàn bộ hệ thống file (/). Nó hoàn toàn không biết gì về thế giới bên ngoài.
Cách đây 2 năm, mình quản lý một cụm server CentOS 7 chạy app legacy dùng PHP 5.6. Khi hệ thống chính cần nâng cấp để vá lỗ hổng, đống thư viện cũ của PHP 5.6 trở thành gánh nặng vì gây xung đột. Thay vì tốn thêm 512MB RAM cho mỗi máy ảo (VM), mình dùng chroot để cô lập đống thư viện cũ. Kết quả? App chạy ổn định, tiết kiệm tài nguyên và quan trọng là không làm bẩn OS chính.
Không chỉ để cô lập, chroot còn là kỹ năng “sinh tồn” khi Linux không thể boot. Nếu bạn lỡ tay cấu hình sai GRUB hoặc quên mật khẩu root, chroot chính là con đường duy nhất để bạn truy cập vào hệ thống đang hỏng từ một bản Live USB.
Chuẩn bị “nhà mới” cho ứng dụng
Lệnh chroot nằm sẵn trong gói coreutils nên bạn không cần cài thêm gì. Cái khó nằm ở chỗ chuẩn bị môi trường. Một phân vùng chroot trống rỗng sẽ không có gì cả, kể cả lệnh ls hay cd.
Hãy thử tạo một môi trường sandbox tối thiểu cho bash:
# Tạo cấu trúc thư mục
sudo mkdir -p /home/jail/{bin,lib,lib64}
Nếu bạn chỉ copy file thực thi /bin/bash vào đó, nó sẽ báo lỗi ngay. Tại sao? Vì Linux cần các thư viện liên kết (.so) để chạy lệnh. Lúc này, lệnh ldd sẽ là trợ thủ đắc lực của bạn.
ldd /bin/bash
Màn hình sẽ liệt kê khoảng 4-5 đường dẫn thư viện. Bạn phải copy chính xác các file này vào đúng cấu trúc thư mục trong /home/jail. Công việc này hơi tốn sức nhưng giúp bạn hiểu rõ bản chất sự phụ thuộc (dependencies) trong Linux.
Hai kịch bản thực chiến đỉnh cao
1. Tạo Jail cô lập (Sandboxing)
Giả sử bạn muốn cho một user vọc vạch hệ thống nhưng không muốn họ táy máy vào dữ liệu thật. Sau khi copy đủ các thư viện cần thiết cho bash và ls, hãy tiến hành “vào tù”:
sudo chroot /home/jail /bin/bash
Thử gõ ls /, bạn sẽ chỉ thấy các thư mục mình vừa tạo. Tuy nhiên, đừng quá chủ quan. chroot không phải là lớp bảo mật thép. Nếu một tiến trình chạy quyền root bên trong jail, nó có thể dùng kỹ thuật double chroot để thoát ra ngoài. Quy tắc vàng: Luôn chạy ứng dụng trong jail bằng user thường.
2. Cứu hộ hệ thống (Rescue Mode)
Đây là kịch bản mình đã dùng hơn 10 lần trong quý vừa qua để xử lý các server vật lý bị sập. Khi server không thể boot vào màn hình login, hãy dùng USB cứu hộ và thực hiện 3 bước sau:
Bước 1: Mount ổ cứng đang lỗi vào thư mục tạm.
sudo mount /dev/sda1 /mnt
Bước 2: Liên kết các tài nguyên phần cứng từ USB vào ổ cứng cũ. Thiếu bước này, các lệnh như apt hay grub-install sẽ tê liệt hoàn toàn.
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
Bước 3: Nhảy vào hệ thống lỗi.
sudo chroot /mnt
Giờ đây, bạn đang đứng ở trung tâm của hệ điều hành bị hỏng. Bạn có thể dùng passwd đổi mật khẩu hoặc update-grub để sửa lỗi nạp hệ điều hành. Sửa xong, chỉ cần exit, unmount và reboot là mọi thứ lại mượt mà.
Mẹo kiểm tra và kinh nghiệm xương máu
Làm sao biết một tiến trình có đang bị “nhốt” hay không? Từ máy thật, bạn hãy soi vào thư mục /proc. Mỗi tiến trình (PID) sẽ có một link root trỏ về thư mục gốc của nó.
# Kiểm tra thư mục gốc của một PID cụ thể
sudo ls -ld /proc/[PID]/root
Nếu kết quả hiện /home/jail thay vì /, nghĩa là nó đang nằm trong diện cô lập. Về hiệu năng, chroot có overhead gần như bằng 0 vì không phải giả lập phần cứng như VM.
Một lưu ý quan trọng: Khi cứu hộ, nếu hệ thống của bạn có phân vùng /boot riêng, hãy nhớ mount nó trước khi chạy các lệnh sửa GRUB. Nếu quên, bạn sẽ chỉ đang update dữ liệu vào một thư mục rỗng, và lỗi vẫn hoàn lỗi sau khi khởi động lại.
Dù Docker đã thống trị thế giới container, hiểu rõ chroot vẫn là một lợi thế lớn. Nó giúp bạn xử lý những ca “khó đẻ” nhất khi server không thể khởi động hoặc khi cần một môi trường thử nghiệm siêu nhẹ.
