Linux 系统级权限误操作救命指南：利用 ACL 实现 “克隆” 恢复

引言：当 chmod -R 变成噩梦

在 Linux 运维生涯中，最令人心跳骤停的瞬间莫过于手滑敲下了 chmod -R 777 / 或者错误的 chown 命令。一旦系统核心文件的权限被破坏，sudo 失效、SSH 无法连接、服务启动报错……整个服务器瞬间变成“砖头”。

重装系统固然是终极办法，但配置环境和迁移数据的成本太高。今天分享一个相对“轻量级”的救命方案：利用 Linux 的 ACL（访问控制列表）工具，从一台健康的同构服务器上“克隆”权限并在故障服务器上还原。

核心原理

Linux 的 acl 软件包中包含两个强大的命令：

getfacl：获取文件/目录的访问控制列表（权限）。
setfacl：设置文件/目录的访问控制列表。

通过导出正常系统的全盘权限表，我们相当于拥有了一份“权限快照”，将其应用到故障机器上，即可修复绝大部分系统文件的权限问题。

准备工作

故障服务器（Target）： 权限已乱，但目前连接未断开（如果连接已断，可能需要挂载光盘进入救援模式操作）。
健康服务器（Source）： 最好是与故障服务器内核版本、发行版版本一致的机器（这样能保证系统文件的路径结构基本一致）。

操作步骤

第一步：在健康服务器上“备份”权限

找一台正常的 Linux 机器，我们将把它的 / 目录下所有文件的权限导出。

Bash

# 在健康服务器执行
# -R 递归
# /  指定根目录
# > systemp.bak 输出到文件

getfacl -R / > systemp.bak

注意：

执行过程中可能会出现 getfacl: Removing leading '/' from absolute path names 的提示，这是正常的。

对于 /proc, /sys 等虚拟文件系统可能会报错，可以忽略，因为这些是内存中的动态文件，重启后会自动重置。

第二步：将备份文件传输至故障服务器

利用 scp 或其他文件传输工具，将生成的 systemp.bak 发送到故障服务器上。

假设你在故障服务器上操作（前提是还能执行命令），想从健康服务器拉取文件：

Bash

# 在故障服务器执行
# root@正常机器IP:/路径/systemp.bak  源文件
# /tmp/systemp.bak                   本地存放路径

scp [email protected]:/root/systemp.bak /tmp/systemp.bak

或者，如果你在健康服务器上操作，想推送到故障服务器：

Bash

1	scp systemp.bak root@故障机器IP:/tmp/systemp.bak

第三步：在故障服务器上“恢复”权限

文件到位后，在故障服务器上执行恢复命令。这会根据备份文件中的路径和属性，重置对应的权限。

Bash

# 在故障服务器执行
# --restore 指定恢复文件

cd /tmp
setfacl --restore=systemp.bak

执行完毕后，系统关键文件（如 /etc/sudoers, /bin/*, /usr/lib/*）的权限应该已经恢复到正常状态。建议此时重启服务器以确保所有服务重新加载正确的权限。

方案局限与风险提示

虽然此方法非常高效，但并非完美，请注意以下几点：

用户数据差异：如果两台服务器上运行的业务不同，或者存在特定的用户目录（如 /home/userA 在健康机器上不存在），这些特异性文件的权限将不会被修复，或者如果用户 ID (UID) 不一致，可能会导致所有权错误。
新增文件：故障服务器上独有的文件，在 systemp.bak 中找不到记录，因此 setfacl 会跳过它们，这些文件的权限可能仍是错误的。
应用场景：此方案最适合刚装完系统不久或高度标准化的集群服务器。

总结

利用 getfacl 和 setfacl 进行权限迁移，是 Linux 运维必须掌握的 Disaster Recovery (灾难恢复) 技巧之一。建议大家在进行高危操作（如批量修改权限）前，先对当前目录执行一次 getfacl -R . > backup.acl，给自己留一颗“后悔药”