chattr +i 是唯一能真正锁死文件的方式，它在内核 VFS 层拦截 write、unlink、rename、truncate 等系统调用，错误统一返回 Operation not permitted；必须用 lsattr 验证输出含 i 字符才生效，加锁前须确认文件系统为 ext4/xfs、SELinux 上下文合规并完成跨挂载点备份。
chattr +i 是唯一能真正锁死文件的方式
用 chmod 444 或 chown root:root 都拦不住 root，只有 chattr +i 能在内核 VFS 层拦截 write、unlink、rename、truncate 等系统调用。错误统一返回 Operation not permitted，不是“权限拒绝”，而是内核直接不放行。
常见误判：执行完 sudo chattr +i /etc/sudoers 后用 ls -l 看权限还是 -rw-r--r--，就以为没生效——必须用 lsattr /etc/sudoers 查，输出里有 i 字符才算成功，例如：----i---------e---。
加锁前必须验证的三件事
跳过任何一项都可能让系统进不了 SSH、起不了服务，甚至无法重启：
-
df -T /path/to/file确认文件系统是ext4或xfs；FAT32、NTFS、overlayfs、NFS挂载点不支持i属性 -
ls -Z /path/to/file检查 SELinux 上下文，若类型是admin_home_t等非标准策略域，chattr +i可能被 SELinux 静默阻断 - 备份到**其他挂载点**：
cp /etc/passwd /backup/passwd.$(date +%s)；加完+i后连cp都会失败，本地备份没用
哪些文件能加 i，哪些绝对不能碰
加 +i 不是设“只读”，而是冻结整个 inode 的写类元操作。适用前提只有一个：该文件「静态、极少变更、且每次修改都必须人工介入」。
可锁的典型目标：
-
/etc/passwd、/etc/shadow、/etc/group：用户身份基线，被篡改等于权限体系崩塌 -
/etc/sudoers：一行错配可能导致全员失权或提权失控 -
/boot/grub2/grub.cfg：启动链第一环，防持久化后门
绝对禁止加 +i 的场景：
- 日志文件（如
/var/log/secure）：rsyslog写入直接报Permission denied，进程崩溃 - 数据库目录（如
/var/lib/mysql）：mysqld启动失败 - 包管理器预期覆盖的文件（如
/etc/ssh/sshd_config升级时）：yum update openssh-server可能卡住或导致 SSH 服务不可用
解锁编辑再重锁的标准流程
别图省事只做 chattr -i → vim → chattr +i。很多服务（如 systemd、NetworkManager）会在后台持续持有文件句柄，强行解锁后立刻被覆盖。
安全操作顺序：
- 先停相关服务：
systemctl stop sshd、systemctl stop rsyslog - 确认无进程占用：
lsof /etc/sudoers或fuser -v /etc/sudoers - 执行
sudo chattr -i /etc/sudoers - 编辑（推荐用
visudo校验语法） - 立即重锁：
sudo chattr +i /etc/sudoers
最危险的疏忽：对 /boot 分区加 +i 后，grub2-mkconfig 或内核升级会静默失败，下次重启可能直接进不了系统——这种问题必须进 live USB 才能救。
