chmod 750 ~ 是合理起点，因 755 允许同组用户遍历家目录泄露敏感配置，而 700 会破坏 docker 等依赖组权限的场景；还需同步修复 ~/.ssh（700）、私钥（600）、~/.gnupg（755）权限，并防范 symlink 空洞与 umask 导致的权限回退。

禁用家目录全局读写权限，不是加个 chmod 就完事——它直接影响 SSH 登录、SSH Agent 转发、~/.ssh/config 生效、甚至某些语言的包管理器（如 npm、pip）的缓存路径行为。

为什么 chmod 755 ~ 不够，而 chmod 750 ~ 才是合理起点

家目录被设为 755 意味着同组用户可遍历（read + execute），只要你在某个共享组里（比如 docker、sudo、或公司统一用户组），别人就能 ls ~ 看到你有哪些隐藏配置、有没有 .aws/、.kube/，甚至直接读取 ~/.gitconfig 或 ~/.profile 中的环境线索。真正需要的是“仅属主+同组可信成员可访问”，所以 750 是最小可行收紧值。

• chmod 700 ~ 更严，但会破坏依赖组权限的场景：比如多用户协作调试时共用 docker 组，docker.sock 访问需组权限，而 docker 客户端默认检查 ~/.docker/ 目录权限，700 可能触发 warning 或拒绝加载 config
• chmod 755 ~ 在大多数 Linux 发行版安装脚本中仍被默认使用，属于历史惯性，不是安全依据
• macOS 默认是 700，但若手动改过权限或通过移动硬盘恢复系统，可能退化为 755，需主动校验

chmod 后必须连带修复的三个关键子目录

只改 ~ 权限没用，SSH 和密钥管理对子目录敏感度远高于根目录。以下三处不修复，ssh 会静默降级为密码登录，ssh-add 报错，git 推送失败。

• chmod 700 ~/.ssh：OpenSSH 严格要求此目录不能被 group/o 写入，否则拒绝加载 id_rsa；即使 ~ 是 750，~/.ssh 若为 755 也会触发 Permissions 0755 for '/home/u/.ssh/id_rsa' are too open
• chmod 600 ~/.ssh/id_rsa（及所有私钥）：公钥（.pub）可为 644，但私钥必须 600；644 或 640 都会导致 OpenSSH 拒绝使用
• chmod 755 ~/.gnupg（如使用 GPG）：GnuPG 2.1+ 要求该目录至少 755，但 700 会导致 gpg: keybox '/home/u/.gnupg/pubring.kbx' not created: Permission denied

空洞审计（directory traversal via symlink）和 chown -R 的连锁风险

所谓“目录空洞”，是指攻击者在你家目录下创建符号链接指向系统关键路径（如 /etc/shadow），再诱使你运行某脚本遍历 ~ 下所有文件——此时看似在操作自己目录，实则读取了 root 文件。单纯 chmod 无法防御这种攻击，必须配合所有权约束与路径解析控制。

• 避免无条件 chown -R $USER:$USER ~：如果 ~ 下存在指向 /root/.bash_history 的 symlink，该命令会把 /root/.bash_history 的属主也改成当前用户，造成越权写入
• 审计空洞的可靠方式是 find ~ -xdev -type l -ls，重点检查是否指向 /etc、/root、/proc、/sys 等非用户可控路径
• CI/CD 或自动化部署脚本中若使用 cp -r 或 rsync -a 恢复家目录备份，需加 --no-D（禁用设备文件）和 --no-s（禁用 symlink 创建），否则可能带入恶意链接

最常被忽略的一点：umask 设置不匹配会导致新创建的文件/目录自动继承宽松权限。即便你手动修好了所有现有路径，下次 touch ~/.newfile 或 mkdir ~/.cache/newdir 还是可能生成 755 目录。检查 umask 输出是否为 0002（对应默认目录 775）或 0022（对应 755），生产环境建议设为 0027，并在 ~/.bashrc 或 /etc/login.defs 中固化。