Quản lý user, group, sudo và quyền thư mục trên Linux server
Tạo tài khoản quản trị, user dịch vụ và thư mục dùng chung trên Ubuntu; chẩn đoán Permission denied theo user, đường dẫn, mode và chính sách truy cập.
Một ứng dụng báo Permission denied không có nghĩa toàn bộ thư mục phải được mở quyền ghi cho mọi người. Trên Linux server, quyền truy cập phụ thuộc vào danh tính tiến trình, quyền trên từng thành phần đường dẫn, ACL và đôi khi cả cơ chế bảo vệ bổ sung. Bài này dùng Ubuntu Server 24.04 LTS để xây dựng một mô hình nhỏ: tài khoản quản trị, tài khoản dịch vụ và thư mục dùng chung có kiểm soát.
Xác định danh tính trước khi sửa quyền
Tài khoản đăng nhập qua SSH có thể khác tài khoản chạy ứng dụng. Nếu bạn sửa quyền dựa trên user đang mở terminal, chưa chắc ứng dụng được hưởng quyền đó. Trước hết kiểm tra:
whoami
id
getent passwd labadmin
getent group sudo
id cho biết UID, primary group và supplementary groups của phiên. getent hỏi cơ sở dữ liệu tài khoản theo cấu hình hệ thống, có thể bao gồm nguồn ngoài /etc/passwd. Với server tích hợp LDAP hoặc Active Directory, đừng tự tạo user trùng danh tính được quản lý tập trung.
Tài khoản có quyền sudo không đồng nghĩa luôn chạy bằng root. sudo thực thi lệnh theo policy, thường yêu cầu xác thực và ghi dấu vết. Làm việc bằng tài khoản cá nhân giúp truy vết tốt hơn việc nhiều người dùng chung một mật khẩu root. Cách tổ chức tài khoản nên theo hướng dẫn user management của Ubuntu.
adduser đặt thông tin và mật khẩu theo tương tác. usermod -aG thêm supplementary group; thiếu -a có thể thay thế danh sách group phụ hiện tại. Group sudo có ý nghĩa theo policy mặc định của Ubuntu; họ RHEL thường dùng wheel, nên không sao chép tên group mà bỏ qua cấu hình sudoers.
Đăng nhập một phiên mới bằng laboperator, kiểm tra id và sudo -v. Phiên đã mở trước lúc thay đổi group thường không tự cập nhật toàn bộ group membership. Không đóng tài khoản quản trị cũ trước khi chứng minh tài khoản mới hoạt động.
Nếu cần cấp quyền giới hạn thay vì quyền quản trị đầy đủ, chỉnh sudoers bằng visudo và thiết kế theo tác vụ cụ thể. Nhiều chương trình có thể mở shell hoặc ghi file tùy ý, nên một rule có vẻ ngắn chưa chắc giới hạn được quyền. Đừng đưa NOPASSWD: ALL vào hướng dẫn mặc định cho server của người mới.
Tạo tài khoản riêng cho dịch vụ
Một dịch vụ không cần home tương tác hoặc quyền sudo có thể dùng system account:
Tài khoản này phục vụ tiến trình, không dành để quản trị qua SSH. Chọn nơi ghi dữ liệu rõ ràng và để cấu hình systemd chỉ định User=labapp ở bài quản lý dịch vụ. Không chạy ứng dụng bằng root chỉ để tránh sửa quyền thư mục.
Tách người triển khai, chương trình đang chạy và dữ liệu có quyền ghi giúp giới hạn phạm vi khi ứng dụng bị lỗi. Ví dụ mã thực thi có thể do quản trị viên sở hữu và không cho service ghi, trong khi /var/lib/labapp dành cho dữ liệu cần cập nhật. Tùy ứng dụng, package có thể đã tạo user và đường dẫn đúng; ưu tiên cơ chế chính thức thay vì tạo thêm danh tính không cần thiết.
Mô hình kỹ thuật để giải thích cơ chế; không phải bằng chứng kiểm thử.
Đọc quyền tệp và quyền đi qua thư mục
ls -ld /srv /srv/team-lab
namei -l /srv/team-lab/report.txt
stat /srv/team-lab/report.txt
Trên file thường, r cho phép đọc nội dung, w cho phép sửa nội dung và x liên quan thực thi. Với thư mục, x là quyền đi qua để truy cập mục bên trong; r cho phép liệt kê tên. Quyền ghi trên thư mục có thể cho phép tạo hoặc xóa mục, dù file đó không cho phép sửa nội dung theo cách thông thường.
Vì vậy, một file có mode 644 vẫn không đọc được nếu user thiếu quyền đi qua thư mục cha. namei -l giúp nhìn toàn bộ đường dẫn. Ngược lại, file read-only không bảo đảm không thể bị xóa khi người dùng có quyền ghi và đi qua thư mục chứa nó, trừ khi các cơ chế bổ sung ngăn chặn.
Các nhóm quyền owner, group và other được chọn theo danh tính, không cộng tùy tiện tất cả quyền có lợi nhất. Khi kết quả thực tế khác dự kiến, xem ACL với getfacl nếu công cụ đã có. Dấu + trong ls -l thường là dấu hiệu có ACL cần đọc thêm.
Mode 2770 đặt setgid trên thư mục, cho phép mục mới thường kế thừa group của thư mục. Nó không tự buộc mọi file mới phải cho group quyền ghi. Mode ban đầu còn phụ thuộc ứng dụng tạo file và umask; file do công cụ chủ động tạo với quyền rất chặt vẫn có thể không chia sẻ được theo mong đợi.
Đăng nhập phiên mới bằng thành viên labteam rồi thử:
Umask trong ví dụ chỉ ảnh hưởng tiến trình shell hiện tại và tiến trình con. Nó không sửa các file đã có, không cấu hình toàn bộ server và không khiến service ở phiên khác nhận cùng giá trị. Đừng thay umask toàn hệ thống chỉ để sửa một thư mục nếu chưa đánh giá tác động.
Kiểm tra bằng tài khoản thành viên thứ hai và bằng một tài khoản không thuộc nhóm. Mục tiêu là thành viên phù hợp đọc/ghi được, còn người không liên quan bị từ chối. Chỉ thử bằng root sẽ bỏ sót lỗi vì root có thể vượt qua nhiều kiểm tra quyền thông thường.
Sơ đồ chẩn đoán: kiểm tra theo từng lớp trước khi thay đổi cấu hình.
Chẩn đoán Permission denied theo từng lớp
Xác định đúng user của tiến trình. Với systemd, đọc unit và thông tin User, Group, SupplementaryGroups.
Kiểm tra đường dẫn thực tế, symlink và quyền từng thư mục cha bằng namei.
Kiểm tra owner, group, mode và ACL của đối tượng đích.
Kiểm tra filesystem read-only, mount option và log bảo vệ ứng dụng nếu quyền Unix có vẻ đúng.
Thay đổi nhỏ nhất cần thiết, thử lại bằng đúng user và ghi lại kết quả.
AppArmor trên Ubuntu, SELinux trên một số distro và sandbox của systemd có thể chặn truy cập ngoài quyền tệp truyền thống. Khi đó tăng mode lên 777 vừa mở rộng quyền không cần thiết vừa không giải quyết lớp đang chặn. Đọc log và tài liệu của cơ chế tương ứng trước khi đổi policy.
chmod -R và chown -R tác động toàn bộ cây thư mục. Chạy vào nhầm root dữ liệu có thể phá quyền của ứng dụng, làm lộ file cấu hình hoặc tạo khả năng sửa mã thực thi. Trước khi dùng đệ quy, giới hạn thư mục, kiểm tra nội dung và lưu thông tin quyền để có cơ sở phục hồi. Không chạy vào /etc, /usr hoặc toàn bộ home theo một công thức chung.
Thu hồi quyền và kết thúc bài lab
Thu hồi tài khoản cần xem cả phiên đang chạy, key SSH, sudoers, cron, service và các nguồn danh tính ngoài máy. Khóa mật khẩu không tự vô hiệu hóa mọi cách đăng nhập bằng key. Với nhân sự rời nhóm, làm theo quy trình quản lý truy cập của tổ chức và kiểm tra các phiên hiện hữu.
Trước khi xóa user, kiểm kê file sở hữu theo UID và quyết định giữ hay bàn giao dữ liệu. Không dùng tùy chọn xóa home nếu chưa xác định rõ dữ liệu cần giữ. Trong lab, bạn có thể giữ các tài khoản phục vụ bài sau rồi xóa khi kết thúc toàn lộ trình.
Hoàn thành khi giải thích được user nào cần quyền gì, thành viên nhóm truy cập đúng, user ngoài nhóm bị từ chối và dịch vụ không cần quyền root. Lưu sơ đồ danh tính cùng đường dẫn, không lưu mật khẩu. Khi quyền liên quan dữ liệu doanh nghiệp hoặc danh tính tập trung, chuyển phương án cho quản trị viên phụ trách xác nhận.
Ghi nhận quyền để người khác tiếp quản
Bảng bàn giao nên gắn thư mục với owner nghiệp vụ và user dịch vụ, nêu rõ ai cần đọc, ai cần ghi và tác vụ nào cần sudo. Khi thay đổi group, ghi cả yêu cầu đăng nhập lại để người dùng không tưởng cấu hình chưa có tác dụng. Với service chạy lâu dài, kiểm tra lại danh tính tiến trình sau restart theo cửa sổ phù hợp.
Nếu file mới vẫn thiếu quyền group, xem umask và cách ứng dụng tạo file trước khi sửa mode bằng tác vụ định kỳ. Một tác vụ tự chmod liên tục có thể che thiết kế quyền sai và tạo khoảng thời gian dữ liệu bị lộ ngoài dự kiến.
Xem thêm Linux Essentials nếu cần ôn kiến thức nền trước khi thực hành.
Lọc log Linux theo service, thời gian và boot; phân biệt lỗi gốc với thông báo hệ quả, kiểm tra quyền đọc và xác nhận phục hồi sau khi sửa nguyên nhân.
