你的电脑，其实一直开着一扇没有锁的后门
你打开电脑，登录系统，打开浏览器刷网页、打开编辑器写代码、打开终端敲命令。你觉得这一切都很正常，对吧？
但你可能不知道的是：在你做这些事的每一秒，电脑里任何一个程序——包括你浏览器里那个来路不明的广告脚本、你刚下载的某个npm包里的代码、你IDE里那个自动补全插件——都可以随时变成“超级管理员”，想看你电脑里任何文件就看，想改任何设置就改，想装什么后门就装。而且整个过程，不需要你输入密码，不需要你点“同意”，甚至连个弹窗提示都不会有。
这不是危言耸听。2026年8月28日，一位安全研究员公开披露了Linux发行版Omarchy的一个默认配置缺陷：系统出厂时就把普通用户直接塞进了“docker”用户组，而在这个组里的人，等于拿到了整台电脑的root权限。任何在你用户会话里运行的程序——不管是你主动装的还是被动跑起来的——都继承了这组权限。一个浏览器标签页被攻破，整台电脑就沦陷了。事情就这么简单。
这个漏洞是怎么一回事：一个Unix socket如何变成整台电脑的“后门钥匙”
Omarchy是由DHH（David Heinemeier Hansson，Ruby on Rails的作者、Basecamp的联合创始人）打造的一款“美观、现代且有明确取向”的Arch Linux发行版。它在GitHub上拥有超过3万颗星。这个系统主打“开箱即用”，给开发者配好了一切——全盘加密、默认防火墙、限速SSH。这些安全措施看起来都很到位。(OpenClaw之父为此项目捐赠100万美金，自家OpenClaw 2.0据说上周要出来，已经沦落到没人照料的孩子，Grok Bot出来Hermes连忙出了Mode模式，OpenClaw毫无动静，永无止境的Bug。)
但有一个配置出了大问题。
Omarchy在默认安装时，把创建的第一个用户自动加进了Linux的docker组。在Arch Linux上，Docker守护进程以root身份运行，监听在一个叫/var/run/docker.sock的Unix socket上。docker组的任何成员都可以跟这个socket通信。Docker官方文档里写得明明白白：docker组成员资格“等同于授予root级特权”。
什么意思呢？就是说，你只要在这个组里，就能通过Docker做任何root才能做的事——启动一个容器、把宿主机的整个文件系统挂载进去、然后以root身份读写任何文件、执行任何命令。不需要sudo，不需要密码，不需要任何权限提示。
我们来做一个实验。在一台受影响的Omarchy系统上，你试着用普通命令读取/etc/shadow——这个文件存着所有用户的密码哈希，正常情况下只有root能看：
console
$ cat /etc/shadow
cat: /etc/shadow: Permission denied
权限被拒，很正常。然后看看你的用户组：
console
$ id
uid=1000(tester) gid=1000(tester) groups=1000(tester),967(docker),992(input),998(wheel)
看到了吗？docker组就在里面。现在用Docker来读同一个文件：
console
$ docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow
root:$6$...
bin:!*:...
daemon:!*:...
整个/etc/shadow文件的内容被完整打印出来了。你运行的还是那个普通用户的命令，但实际干活的是以root身份运行的Docker守护进程。整个过程静悄悄的。没有密码弹窗。没有“你确定吗”的提示。什么都没有。
这就怪了，对吗？
“我不用Docker就没事”？错，你电脑里每个程序都有这把钥匙
很多人听到这里可能会想：“我又不用Docker，跟我没关系。”这是最大的误解。
Linux的附加组（supplementary groups）是会被子进程继承的。也就是说，你登录之后启动的每一个程序——不管是你的终端、浏览器、编辑器、IDE、还是后台服务——都继承了docker组的权限。安全研究员遍历了用户systemd --user实例下方的进程树，发现会话中几乎所有正常进程都带有docker组。
这意味着什么？
你浏览器里一个被污染的JavaScript广告，可以通过浏览器漏洞执行系统命令，然后通过Docker拿到root。你跑一个npm install，里面某个依赖包带了恶意postinstall脚本，直接提权。你的AI编程助手——那个帮你写代码的agent——如果被喂了恶意指令，也能瞬间拿到整台机器的控制权。你IDE里的某个插件、某个主题包、某个自动补全工具——只要其中任何一个被攻破，结果都一样。
换句话说，一个普通用户应用程序被攻破，可以立即演变为整台机器被完全控制。这不是“可能发生”的风险，这是“已经敞开了大门”的现实。
“选择退出”vs“选择加入”：一个没有告诉用户的安全取舍
这个配置还有一个更让人不安的地方。
Omarchy把用户加入docker组，是默认行为，是“opt-out”（选择退出），而不是“opt-in”（选择加入）。用户不需要主动开启这个功能，甚至不需要知道这个功能的存在。安全权衡是被替用户做出的，施加在默认账户上，而且没有向用户解释这一权衡。
很多用户会合理地假设：操作系统默认是安全的，如果有不安全的设置，系统会告诉我、会让我选择。但Omarchy没有这么做。它替你做了决定，然后把后果藏在了文档的某个角落里。
Omarchy确实在开发工具文档里提过这件事。原话是：“Omarchy安装了运行[docker]所需的一切。这包括……让你以普通用户而非root身份运行Docker所需的用户组变更。”
这句话的措辞非常微妙。“以普通用户而非root身份运行Docker”——一个普通读者读到这里，很可能会理解为Omarchy已经配置了某种“rootless Docker”（无根模式），让Docker在不需要root权限的情况下运行。但事实完全相反。Docker守护进程依然以root身份运行，socket依然在那里敞开着。所谓“以普通用户身份运行”，只是省去了你每次打sudo的步骤——而省掉这个步骤的代价，是你把整台电脑的root权限拱手送给了每一个能接触到这个socket的程序。
一年多的时间里，这个配置经历了什么
这个漏洞不是一天两天的事。从代码提交记录来看，整个过程持续了超过一年。
2025年6月1日，docker组成员资格被引入Omarchy的默认配置。第二天，也就是6月2日，这个配置被临时禁用。但到了6月17日，它又被重新启用了。然后就这么一直保留着，通过了3.x系列的多个版本发布，一直到2026年8月——安全研究员通过项目的“负责任披露”流程私下报告了这个问题。8月24日，项目团队提交了一个修复，移除了默认的docker组添加逻辑。8月25日，Omarchy 4.0.1版本发布，包含了这个修复以及其他一系列安全补丁。
从引入到彻底移除，这个配置存在了将近15个月。其间经历了3.8.4及之前的所有版本。无数用户在这段时间里安装了这个系统，从头到尾不知道自己电脑上一直开着这么一扇门。
开发者的机器为什么是最肥的靶子
这件事放在一个更大的背景下看，就更让人坐不住了。
开发者是攻击者的高价值目标。为什么？因为开发者的机器上通常攒了一堆东西：生产系统的SSH密钥、云服务的API令牌、源代码仓库的访问凭证、数据库的连接字符串——这些东西经常以明文形式躺在dotfile里。开发者为了方便，往往会关掉各种安全护栏。而一旦开发者的机器被拿下，攻击者可以利用这些凭证污染软件供应链、直接入侵生产系统。
这不是假设。近年来已经有无数的报告证实了这一点：开发者机器被攻破，然后整个公司的代码仓库被投毒、生产环境被渗透。
在这种背景下，一个操作系统默认给每一个普通用户进程发一把root钥匙——这已经不是“疏忽”能概括的了。
当然，把用户加入docker组这个操作本身，在很多Linux系统上确实是一个常见的便利性配置。很多开发者会手动执行这个操作，省得每次打sudo。区别在于：手动操作是你自己做的决定，你知道自己在干什么，你也知道风险。而Omarchy替所有用户做了这个决定，还没有告诉他们风险是什么。
问题修了，但更大的问题还在
Omarchy团队在接到报告后的响应速度是值得肯定的。修复方案也很彻底：默认不再把用户加入docker组；如果用户想开启“免sudo Docker”，需要主动到“设置 > 安全”菜单里手动开启，而且系统会明确警告风险。已有的安装也会在升级时自动把用户从docker组里移除。4.0.1版本还包含了一系列其他安全修复。
但问题在于：一个面向开发者的、标榜“有明确态度”的操作系统，在安全默认值这件事上出了这么大的纰漏，而且还持续了这么久——这让人不得不质疑它的安全决策流程。Omarchy不是第一次出现安全问题。在它光鲜的README和精美的手册背后，安全这件事到底被放在了什么位置？
Docker官方文档里写得很清楚：把用户加入docker组“比sudo更危险”，因为Docker没有sudo那样的密码检查和审计日志。任何针对docker组成员的代码执行漏洞，都相当于直接给了攻击者root权限。安全社区的主流建议是：永远不要把任何用户——包括你自己——加入docker组。
但Omarchy不仅这么做了，还把它做成了默认配置。而且文档里的描述还让用户以为这是某种“无根模式”。这已经不是“疏忽”了，这是信息误导。
还有别的路吗：Podman和“无根”容器
说到这里，一个自然的问题是：那我到底该怎么跑容器？
如果你用Docker on Linux，又不想被迫把root权限拱手让人（哪怕是每次输一次sudo），Podman是一个值得认真考虑的替代方案。Podman是无守护进程（daemonless）的。你的容器作为普通子进程运行在自己的用户命名空间里，不需要任何root访问权限。Podman默认就是rootless模式，开箱即用。而Docker要达到同样的安全姿态，需要手动做大量加固配置。
当然，Docker和Podman之间不是100%兼容的。但如果你只是日常开发、跑跑容器服务，Podman的替代成本正在快速下降。
但这里有一个更深层的问题：很多人把容器本身当成了一种安全隔离手段。这是错的。容器不是安全屏障。如果你指望容器来保护你的操作系统不被容器里的应用搞破坏，你从一开始就想错了方向。容器主要解决的是分发和部署的一致性问题，不是安全问题。
一个还没讲完的故事
Omarchy 4.0.1已经发布了。如果你在用这个系统，赶紧更新。如果你之前在3.x版本上跑过任何不可信的代码——npm脚本、浏览器插件、AI agent、随便什么——你的机器可能已经被人光顾过了。去查查你的SSH密钥、API令牌、生产环境凭证。别问“要不要查”，问就是“已经该查了”。
但故事到这里并没有结束。一个更棘手的问题是：你的操作系统里还有多少类似的“默认配置”，正在安安静静地替你做着你不知道的安全决定？
Omarchy的这次漏洞被发现了、报告了、修了。但那些没被发现的呢？那些藏在其他发行版里、藏在其他“开箱即用”工具里、藏在那些为了方便而默认开启的配置里的呢？
你没法回答这个问题。我也没法回答。而这就是最让人不安的地方。