必须用专用低权限用户运行Python应用：创建不可登录的系统用户（useradd -r -s /usr/sbin/nologin -U myapp），程序目录设为/opt/myapp/且权限750，配置文件600，虚拟环境由myapp用户创建，通过systemd以User=myapp启动并指定WorkingDirectory，最后验证进程UID和越权限制。
直接用 root 或普通登录用户跑 Python 应用，等于把整台服务器的钥匙交给它——哪怕只是一行 os.system("rm -rf /") 的 bug，或一个未打补丁的反序列化漏洞，都可能让整个系统瘫痪。必须用专用低权限用户运行。
创建不可登录的服务用户
不能复用 nobody、daemon 这类系统级通用账户，它们常被多个服务共享，一旦某个服务被攻破，攻击者可借其横向提权。也不能用带交互 shell 的普通用户（如 /bin/bash），否则可能被利用执行任意命令。
- 用
useradd -r -s /usr/sbin/nologin -U myapp创建系统用户：-r表示系统账户（UID 默认 1–999），-s /usr/sbin/nologin彻底禁用登录能力 - 避免手动改 UID/GID 数字（如
usermod -u 1000 myapp），不同发行版对 UID 范围定义不一；优先依赖-r自动分配 - 确认账户无密码且无法 SSH 登录：
sudo grep myapp /etc/shadow应显示!或*开头
设置程序目录与文件权限
服务用户必须只能访问自己需要的路径，其他一概拒绝。常见错误是把代码放在 /home/myapp/ 下——家目录默认有 755 权限，外部用户可遍历；或把配置文件设为 644，导致敏感信息泄露。
- 程序根目录建议用
/opt/myapp/或/usr/local/myapp/，属主设为myapp:myapp，权限750 - Python 虚拟环境（如
venv）必须由myapp用户创建并拥有，不能用root初始化后 chown —— 某些 pip 安装行为会残留 root 权限文件 - 配置文件（如
settings.py、.env）权限必须是600，且不能放在 Web 可访问路径下（如 Nginx 的root目录内）
通过 systemd 以指定用户启动
别用 sudo -u myapp python app.py 手动起进程——没守护、无日志、崩溃即死。systemd 是 Linux 生产环境的事实标准，但写错 User= 字段或漏掉 WorkingDirectory 会导致权限拒绝或路径错误。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
立即学习“Python免费学习笔记（深入）”；
-
User=myapp和Group=myapp必须显式声明，不能只写User=1001（数字 UID 在跨机器部署时不可靠） - 务必加
WorkingDirectory=/opt/myapp，否则 Python 导入模块或读取相对路径配置会失败 - 若应用需访问网络端口（如绑定 8000），确保该端口未被占用，且防火墙放行；Linux 不允许非 root 绑定 1024 以下端口，不要硬改
setcap—— 改用 Nginx 反向代理更安全
验证是否真降权成功
很多人以为写了 User=myapp 就万事大吉，但实际进程仍可能以 root 身份运行——比如 Gunicorn 启动脚本里用了 sudo，或 Python 代码里调了 os.setuid(0)。
- 查进程真实 UID：
ps aux | grep myapp→ 看 USER 列是否为myapp；再用cat /proc/$(pgrep -f "gunicorn.*myapp")/status | grep Uid确认四个 UID 全部一致 - 模拟越权操作测试：切换到
myapp用户，执行touch /etc/test或cat /etc/shadow，应明确报 Permission denied - 检查日志输出路径权限：如果日志写到
/var/log/myapp/，该目录必须属myapp:myapp且权限750，否则 systemd 会因无法写日志而静默失败
最容易被忽略的是虚拟环境初始化和日志目录权限——前者常因用 root 创建导致内部脚本保留 setuid 位，后者常因忘记 chown 导致服务启动时卡在“failed to write log”却无报错。每次部署后，必须进容器或机器里手动切到服务用户跑一遍启动命令，看它能不能真正走通。
