大家好，我是良许。
前两天有个哥们在群里发了个救命信号，说手滑把 chmod 命令的权限改成了 000，整个人都麻了。
这事儿听起来像段子，但真遇上了，那可是要命的操作。
chmod 没了执行权限，你就没法用 chmod 去改权限，这不就成死循环了吗？
为什么会出现这种致命操作
说白了，就是手快脑子没跟上。很多人在服务器上批量改权限的时候，习惯性地敲 chmod -R 000 /some/path，结果路径没写对，或者直接手抖把 /usr/bin/chmod 给改了。
还有一种情况是写脚本的时候，变量没赋值好，导致 chmod 把自己给废了。
这种事儿在凌晨三点加班改配置的时候特别容易发生，困得眼睛都睁不开，手指头在键盘上乱飞，等反应过来的时候，chmod 已经躺平了。
更要命的是，很多公司的生产环境还没有快照备份，这一下就真的是叫天天不应了。
几种实战恢复方案
方案一：用 Perl 救场
Linux 系统里一般都自带 Perl，而 Perl 可以直接调用系统调用来修改文件权限。
这招算是最快的：
perl -e 'chmod 0755, "/usr/bin/chmod"'
一行命令搞定，chmod 立马复活。
这个方法的原理是绕过 chmod 命令本身，直接通过 Perl 的 chmod 函数去操作文件系统。
方案二：Python 也能顶上
如果服务器上有 Python（现在哪台服务器没 Python 啊），那就更简单了：
python -c "import os; os.chmod('/usr/bin/chmod', 0o755)"
或者 Python 3：
python3 -c "import os; os.chmod('/usr/bin/chmod', 0o755)"
这个方法和 Perl 一个道理，都是通过编程语言的系统调用接口来改权限。
方案三：从其他机器拷贝
如果你有另一台相同系统的机器，可以直接把正常的 chmod 拷过来：
scp user@other-server:/usr/bin/chmod /tmp/chmod
/tmp/chmod 755 /usr/bin/chmod
注意要先拷到 /tmp 目录，因为 /tmp 一般都有执行权限。
这招适合有多台服务器的场景，但要确保系统版本一致，不然可能会有兼容性问题。
方案四：用 busybox 救命
有些精简系统会装 busybox，它自带了一套独立的工具集：
busybox chmod 755 /usr/bin/chmod
busybox 就像是 Linux 工具箱的备胎，关键时刻能救命。
方案五：LD_PRELOAD 黑科技
这个方法比较硬核，适合实在没办法的情况。
可以写个共享库来劫持系统调用：
// fix_chmod.c
#include<sys/stat.h>
intchmod(constchar *path, mode_t mode){
return syscall(90, "/usr/bin/chmod", 0755);
}
编译后用 LD_PRELOAD 加载，但这个方法太复杂，一般不推荐。
方案六：LiveCD 大法
实在不行就用 LiveCD 或 U盘启动盘进系统，挂载硬盘后直接改：
mount /dev/sda1 /mnt
chmod 755 /mnt/usr/bin/chmod
这招最稳，但需要物理接触服务器，云服务器就比较麻烦了。
如何避免再次踩坑
这种低级错误其实完全可以避免。
首先，操作生产环境之前一定要先在测试环境验证，别直接在线上瞎搞。
其次，写脚本的时候多加几层检查，尤其是涉及到权限修改的操作，最好加个二次确认。
还有就是养成备份的习惯，不管是快照还是定期备份，关键时刻能救命。
很多人觉得备份麻烦，但真出事了才知道，那点时间成本根本不算什么。
另外，操作敏感命令的时候，可以给自己设置个别名，比如把 chmod -R 改成需要确认的版本，或者干脆用 chmod -c 让它输出修改信息，这样至少能及时发现问题。
最重要的是，别在状态不好的时候操作服务器。
困了就睡觉，别硬撑着改配置，手滑一次可能就是一个通宵的代价。
