Linux应用权限需求取决于进程UID/GID与目标资源权限位的匹配结果：进程有效UID/GID决定基础能力边界，文件目录权限位约束具体操作，网络设备等资源则受capabilities或组权限管控。
应用执行时对系统权限的需求，不是由“功能强弱”决定的，而是由它要访问的资源类型和操作动作直接触发的。核心逻辑很朴素：进程能做什么，取决于它运行时的身份（UID/GID）和目标资源的权限设置，两者匹配才允许操作。
进程身份决定基础能力边界
Linux 中每个进程都有四个关键身份标识：真实 UID/GID、有效 UID/GID。其中有效 UID是权限检查时真正起作用的那个。普通用户启动的应用，默认有效 UID 就是该用户的 UID（比如 1001），因此它天然无法写入 /etc/、修改其他用户家目录、绑定 1–1023 端口等。
常见情况：
- Web 服务（如 Nginx）通常以非 root 用户（如 www-data 或 nginx）运行，仅在启动时用 root 绑定 80/443 端口，随后主动降权——这是最小权限原则的典型实践
- 数据库服务（如 PostgreSQL）默认用专用系统用户（postgres）运行，数据目录归属该用户，避免被其他进程误改
- 脚本或工具若需修改系统配置，必须通过 sudo 显式提权，而不是让整个进程长期以 root 运行
文件与目录权限决定具体可操作项
即使进程拥有较高 UID，仍受目标文件权限位约束。例如：
- 一个 root 进程想读取 /home/alice/.ssh/id_rsa，但该文件权限是 600（仅 owner 可读写），而进程有效 UID 不是 alice —— 依然读取失败
- 日志轮转脚本需要向 /var/log/myapp/ 写入新日志，该目录若属 group myapp 且权限为 775，那么只要进程的有效 GID 是 myapp，或属于该组，就能写入
- 可执行文件是否带 SUID 位（如 /usr/bin/passwd），会临时切换有效 UID 为目标文件所有者，实现有限提权
网络与设备资源同样受权限模型管控
权限控制不止于文件系统：
- 绑定低端口（1–1023）需 CAP_NET_BIND_SERVICE 能力或 root 权限；现代做法常用 systemd 的 AmbientCapabilities 或 setcap 工具赋予细粒度能力，而非全权提权
- 访问 /dev/sda 等块设备，依赖进程所属组（如 disk 组）及设备文件权限（如 brw-rw---- 1 root disk）
- 使用 ptrace 调试其他进程、加载内核模块、修改系统时间等操作，均对应独立的 Linux Capabilities，可单独启用或禁用
生产环境应遵循的权限设计逻辑
判断一个应用需要什么权限，不能只看“它想干什么”，而要看“它必须接触哪些资源、以什么方式接触”：
- 列出它读写的全部路径，确认对应目录/文件的 owner/group 和权限码（用 ls -l 验证）
- 检查它是否监听网络端口，特别是是否低于 1024；若必须，优先用 authbind 或 capabilities 替代 root
- 识别它调用的系统调用（strace 可辅助），对照 capabilities 手册页，剥离不必要的特权
- 避免用 chmod 777 或 chown root:root 解决问题——这暴露的是权限设计缺陷，不是权限不足
