如何在Linux中配置权限修复脚本

Table of Contents

权限修复脚本一旦跑偏，轻则服务中断，重则系统瘫痪（比如 chmod -R 777 / 这种操作）。核心原则是：**默认只看、不改；改之前先记录原始状态；只动明确知道该动的路径**。

实操建议：

所有脚本开头加 set -e，任一命令失败立即退出，避免半途而废留下脏状态
用 stat -c "%U:%G %a %n" $PATH 把待修路径的原始权限存到临时文件，例如 /tmp/venv_perms_before_20260707.log
默认启用 dry-run 模式：所有 chmod 和 chown 命令前加 echo，输出将执行什么，但不真执行
加 -y 参数才真正执行，例如 ./fix_venv_perms.sh -y --group devteam
禁止对 /etc、/bin、/usr 等系统目录递归操作——这类路径必须硬编码白名单，不能靠模糊搜索

硬写 ./venv 或 ./.venv 路径会漏掉真实部署场景：有人用 env，有人放在 deploy/.venv，还有人用 Poetry 管理的 .venv 在项目外。必须动态探测。

实操建议：

优先检查脚本第一个参数：[ -n "$1" ] && [ -d "$1" ] && [ -f "$1/pyvenv.cfg" ] && VENV_DIR="$1"
否则向上两级搜索：find . .. ../.. -maxdepth 1 -name "pyvenv.cfg" -printf "%h\n" | head -n1
再 fallback 到常见名检查：for d in venv .venv env; do [ -d "$d/bin/activate" ] && VENV_DIR="$d" && break; done
最后验证：[ -z "$VENV_DIR" ] && echo "ERROR: no venv found" >&2 && exit 1

bin/ 里全是 shell 脚本和可执行链接（如 python、pip），没 x 权限就调不起；lib/ 下绝大多数是 .pyc 或 .so 文件，不该有 x 权限，否则可能被意外执行或扫描出漏洞。

实操建议：

bin/ 目录：递归 chmod 775 bin/，确保所有文件可执行、组可写（协作时 pip install 才能写入）
lib/ 和 include/：先 find lib/ -type f -exec chmod 644 {} \;，再 find lib/ -type d -exec chmod 755 {} \;
pyvenv.cfg 和 activate：保持原属主，仅补组读权限：chmod 644 pyvenv.cfg activate
跳过 lib/python3.x/site-packages/ —— 这里由 pip 管理，强行改可能破坏 wheel 安装逻辑

权限数字对了，不代表用户能顺利运行 python -m pip list 或 source bin/activate。关键要走通实际链路。

实操建议：

切换到协作用户（非创建者）执行：su -s /bin/bash -c "source ./venv/bin/activate && python -c 'import sys; print(sys.executable)'" devuser
检查 venv/bin/python 是否能被组内其他用户执行：getent group devteam | grep $(whoami) 确认在组里，再手动 chmod 后 ls -l venv/bin/python 看是否含 rx 给 group
验证 pip 安装能力：sudo -u devuser bash -c "cd /tmp && source /path/to/venv/bin/activate && pip install --dry-run requests"
特别注意 venv/lib/python3.x/ 下的 _sysconfigdata*.py 文件——如果它属主是 root 且权限 600，普通用户 import ssl 就会报错