非root用户在Docker容器内可绑定80端口的原因是什么

本质逻辑：两套独立的Linux权限校验并行生效 #

你观察到的权限矛盾，本质是Linux权限体系不是单一规则，而是多维度并行校验的结果，不存在逻辑冲突：

• 你测试的touch /root/foo报错、无法通过sudo/su切换root，属于基于UID/GID的文件系统权限校验范畴：你创建的container用户UID为1000，不具备root（UID 0）对应的文件访问权限，因此这类操作的表现完全符合对非root用户的常规预期。
• 你成功绑定80端口的行为，属于基于Linux Capabilities的内核网络权限校验范畴：这类权限和用户的UID身份没有强绑定关系。传统物理机/桌面Linux环境下，默认只有root启动的进程会获得CAP_NET_BIND_SERVICE权限（允许绑定1024以下的特权端口），但Docker的安全模型会主动调整这部分权限的分配规则。

Docker的默认权限设计 #

Docker默认会为所有启动的容器分配一组经过裁剪的最小必要Capabilities白名单，其中就包含CAP_NET_BIND_SERVICE。这部分权限属于容器级的安全上下文，不区分容器内运行进程的用户身份：只要是容器内启动的进程，都会自动继承这部分能力，无论你用root用户还是自定义的非root用户启动。
也就是说，你在容器里虽然是UID 1000的普通用户，但你的进程天生具备绑定1024以下端口的内核权限，自然可以成功启动80端口的HTTP服务。

Docker for Mac环境的影响 #

这个现象和你使用的Docker for Mac环境没有关联。Docker for Mac只是通过内置的轻量Linux虚拟机模拟了完整的Docker运行环境，容器内的权限校验逻辑和原生Linux主机上的Docker行为完全一致——把同一份自定义镜像拿到原生Linux服务器上运行，用非root用户依然可以成功绑定80端口。

• 直接将物理机环境下「特权和root用户身份完全绑定」的逻辑套用到容器环境。物理机的特权分配是“全有或全无”：用户是root就获得所有内核权限，不是root就拿不到任何特权端口权限。但容器环境的特权模型是拆分的，会主动剥离绝大多数危险的内核特权，只保留少量常用能力，这些能力的分配不随容器内的用户身份变化。
• 误以为Linux权限是统一的校验规则。实际上Linux权限体系是多维度独立生效的：文件访问权限、网络操作权限、强制访问控制规则互不耦合，某一类权限的限制不会自动传导到其他权限维度。

• 在容器内执行cat /proc/self/status | grep CapEff，拿到的有效能力位掩码中，对应CAP_NET_BIND_SERVICE的位是置1的，可以直接证明当前进程具备绑定低端口的权限。
• 如果需要复现非root用户无法绑定80端口的效果，只需要在启动容器时增加参数--cap-drop NET_BIND_SERVICE，移除容器默认分配的低端口绑定权限，此时非root用户启动服务绑定80就会正常抛出权限拒绝的报错。

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