安全圈最近披露了一个很有意思的漏洞：Linux 发行版 Omarchy 的默认配置，让用户会话里的任何进程都能无密码、无提示地提权到 root。不是某个软件写错了，而是安装系统时"顺手"把默认用户加进了 docker 组——就这么一行配置，把整台机器的安全底线击穿了。

docker 组，就是 root 的另一种写法

问题出在一个很多开发者天天接触的细节上：能操作 Docker 的用户，本质上等同于 root。Docker 守护进程以 root 身份运行，凡是能跟它通信的人，都可以让它挂载宿主机任意目录、以 root 执行任意命令。Omarchy 把默认用户加进 docker 组，等于给每个登录用户发了一张"root 通行证"，而且全程不需要任何密码。

更隐蔽的是它的传播范围。Linux 的组权限会被子进程继承，所以浏览器、编辑器、npm 脚本、后台服务——凡是用户会话里能跑代码的地方，全都拿到了这张通行证。安全研究者实测：一条 docker 命令就能直接读出 /etc/shadow 里的密码哈希。

危险的不只是漏洞，还有"默认"

这个案例最值得警惕的地方，在于它是opt-out 而不是 opt-in：用户没有主动选择使用 Docker，安全风险却默认扣在了每个人头上，而且系统从未解释过这个权衡。绝大多数用户根本不知道"我在 docker 组里"意味着什么。

AI 编程代理的普及让这个问题雪上加霜。如今越来越多的开发者在终端里跑 AI 编码工具，这些工具会执行任意命令。放在一个"全员可提权"的系统里，一次提示词注入、一个被污染的依赖，就可能直接演变成整台机器失守——从"代码被改"升级成"机器被控"。

给运维和开发者的三条启示

第一，定期检查组成员。用 id 命令看看自己和关键账号在哪些组里，docker、sudo、wheel 这类敏感组，成员必须精打细算。

第二，默认安全，而不是默认便利。任何系统、任何工具的默认配置，都应该先问"最坏情况下这会造成什么后果"，而不是"这样用起来方不方便"。

第三，给 AI 编程工具上"笼子"。AI 编码代理能读能写能执行，就该按"不可信程序"对待：跑在隔离环境、限制文件访问范围、对敏感操作二次确认。权限给得越少，出事的半径就越小。

安全默认值，是最便宜的防线

这个漏洞的修复其实很简单——把用户移出 docker 组，升级到 4.0.1 即可。但它的启示比补丁本身值钱：安全不是事后打补丁，而是从默认配置的第一行就开始设计。对正在把开发流程 AI 化的团队来说，这句话尤其值得刻在 CI/CD 管道的入口处。

服务器机柜