误修改/usr目录权限后出现std::bad_alloc错误的技术求助

手动修复/usr权限这种操作很容易留下隐性问题，你遇到的偶发std::bad_alloc错误大概率还是权限修复不彻底导致的——毕竟交互式Python没问题，脚本执行时的环境依赖（比如加载的系统库、执行上下文）和交互式有差异，刚好触发了权限错误的环节。下面给你几个具体的排查方向：

1. 用系统包管理器验证文件完整性与权限 #

手动对比ls -lha很容易漏掉细节，比如SUID/SGID位、文件属性、甚至文件内容是否被意外修改。Ubuntu的dpkg工具可以帮你批量检查：

• 执行dpkg --verify，这个命令会列出所有和包定义不一致的文件：
  • 输出开头的5表示权限/属性错误
  • 8表示文件大小/哈希不一致（内容损坏）
• 可以过滤出权限相关的问题：dpkg --verify | grep -E '^[58]'
  重点关注/usr/bin/python*、/usr/lib/python*以及/usr/lib/x86_64-linux-gnu/下的系统库文件，这些是Python运行时的核心依赖。

2. 重点检查Python相关二进制与库的SUID/SGID权限 #

虽然你修复了passwd、sudo的SUID，但Python本身或者它依赖的某些系统库可能也需要特殊权限。比如：

• 对比正常机器上/usr/bin/python3的权限（18.04默认是-rwxr-xr-x，一般没有SUID，但要确认owner/group是root:root）
• 检查/usr/lib/python3.6/（对应你的Python版本）下的所有文件，确保owner/group都是root:root，权限位和正常机器一致——尤其是site-packages之外的核心库文件。
• 还要注意系统C库（比如/usr/lib/x86_64-linux-gnu/libstdc++.so.6）的权限，std::bad_alloc是C标准库抛出的错误，这个库的权限如果不对，会导致内存分配逻辑异常。

3. 排查脚本执行的环境差异 #

交互式Python和脚本执行的环境可能有区别，比如：

• 脚本是否用了不同的Python解释器？检查脚本开头的#!/usr/bin/env python或者#!/usr/bin/python3对应的二进制权限是否正确。
• 查看脚本执行时的环境变量：在脚本开头加上print(os.environ)（导入os模块），和交互式执行的os.environ对比，看是否有异常的环境变量（比如LD_LIBRARY_PATH被修改，导致加载了错误的库）。
• 检查资源限制：执行ulimit -a，对比交互式和脚本执行时的限制（比如栈大小、虚拟内存上限），虽然std::bad_alloc一般不是资源限制导致，但偶尔也会因为权限问题触发异常的限制。

4. 测试最小化脚本缩小范围 #

写一个极简的Python脚本（比如只打印一行内容），反复执行看是否会报错：

print("Hello World")

如果这个脚本也偶发错误，那问题肯定在Python核心或者系统库的权限上；如果只有复杂脚本报错，那要排查脚本用到的第三方库、文件IO操作的权限——比如脚本是否读写了某些需要特殊权限的文件，或者用到的第三方库的安装目录权限异常。

5. 补充检查文件扩展属性 #

有些系统文件会有扩展属性（比如security.capability），手动修改权限时可能会丢失。用getfattr命令查看正常机器上的关键文件（比如/usr/bin/python3、/usr/lib/libstdc++.so.6）的扩展属性，对比你的机器：

getfattr -d /usr/bin/python3

如果有差异，用setfattr同步过来。

最后，你计划用正常机器的ls -lha /usr对比是个好办法，但建议同时对比文件的权限位（包括SUID/SGID的s位）、owner/group，甚至用md5sum对比关键文件的哈希值，确保文件内容没有被意外修改。

内容的提问来源于stack exchange，提问作者user3389288