开发者生态
morning
使用 FamilyWild 在主机之间共享 X11 服务器
摘要
2026-08-02 Sharing an X Server Across Hosts with FamilyWild Ever tried running an X11 application from inside a container, a chroot, or over ssh with a bind-mounted .Xauthority — only to be greeted by...
the
cookie
client
and
hostname
Xauthority
family
with
The
xauth
2026-08-03
1 阅读
约7分钟阅读
shirozuki
字号:
2026-08-02 与 FamilyWild 跨主机共享 X 服务器 曾经尝试过从容器内部、chroot 或通过 ssh 使用绑定安装的 .Xauthority 运行 X11 应用程序 — 只是收到了永远有用的“需要授权,但没有指定授权协议”?该文件就在那里,以只读方式安装在客户端期望的位置,但 X 拒绝连接。原因很微妙,修复方法是一行 sed 。为什么 cookie 被拒绝 .Xauthority 文件是 cookie 列表,每个条目都以家族和主机名作为键控。当客户端连接时,它不仅会获取找到的第一个 cookie,还会查找主机名与客户端认为其正在运行的计算机相匹配的条目。这正是客户端在 cookie 生成地以外的地方运行时中断的原因。容器内部的主机名是不同的;通过未转发的套接字,客户端解析完全不同的名称。该 cookie 存在且有效,但其主机名不匹配,因此客户端永远不会提供它,并且 X 会退回到“无授权协议”。您可以自己查看 family/hostname 键控: $ xauth list myhost/unix:0 MIT-MAGIC-COOKIE-1 a1b2c3d4e5f6... 领先的 myhost/unix:0 是问题所在 - 它将 cookie 固定到 myhost 。 FamilyWild 可以拯救 X 有一个通配符系列 FamilyWild ,其数值为 0xffff 。该系列中的 cookie 与任何主机名匹配。因此,我们不会尝试使客户端的主机名与 cookie 匹配,而是重写 cookie 以匹配每个主机。 xauth nlist 以数字格式打印条目,其中第一个字段是 4 个十六进制数字系列。用 ffff 覆盖它并将结果合并到新文件中: : > /tmp/portable.Xauthority && xauth nlist :0 | \ sed 's/^..../ffff/' | xauth -f /tmp/portable.Xauthority nmerge - # 将 :0 替换为您的 $DISPLAY 值 更改是单个字段 值得一看的是编辑有多小。 .Xauthority 条目是打包的二进制记录:一个 2 字节系列,然后是长度前缀的地址、显示编号、身份验证名称和 cookie 本身。转储原始文件,该系列位于前两个字节 - 0100 ,即 FamilyLocal : 00000000: 0100 0006 6d79 686f 7374 0001 3000 124d ....myhost..0..M 00000010: 4954 2d4d 4147 4943 2d43 4f4f 4b49 452d IT-MAGIC-COOKIE- 00000020: 3100 10a1 b2c3 d4e5 f607 1829 3a4b 5c6d 1.........):K\m 00000030: 7e8f 90 ~.. 现在转储我们刚刚构建的 FamilyWild 版本。一切都是逐字节相同的 - 相同的 myhost 地址,相同的 cookie - 除了前两个字节,现在翻转为 ffff : 00000000: ffff 0006 6d79 686f 7374 0001 3000 124d ....myhost..0..M 00000010: 4954 2d4d 4147 4943 2d43 4f4f 4b49 452d IT-MAGIC-COOKIE- 00000020: 3100 10a1 b2c3 d4e5 f607 1829 3a4b 5c6d 1..........):K\m 00000030: 7e8f 90 ~.. 那一个字段是整个技巧:地址字节仍然拼写为 myhost ,但 X 不再关心,因为系列 0xffff 无条件匹配。无论客户端在何处运行,都绑定挂载(或 scp )/tmp/portable.Xauthority,将 XAUTHORITY 指向它,无论主机名不匹配,连接都会被接受。 xhost+ 怎么样?您经常会看到 xhost + 建议作为“让它工作”的答案,并且它确实如此 - 通过完全关闭基于主机的访问控制。然后,每个主机的每个客户端都可以连接到您的显示器,而无需任何 cookie。在单用户机器上,这听起来无害,但 X 在客户端之间没有隔离:任何可以访问服务器的人都可以读取您的击键,抓取任何窗口的内容,并注入合成输入。 xhost + 将这种能力交给每个本地用户,如果您的服务器侦听 TCP,则将这种能力交给网络。即使是更窄的 xhost +local: 仍然信任盒子上的每个 UID。 FamilyWild cookie 可以让门保持锁定状态(客户端仍然必须提供秘密),同时仅删除妨碍的主机名限制。使用它而不是 xhost + ,并将 cookie 文件保留在 0600 处。一个警告 FamilyWild cookie 故意比它所取代的 cookie 更不具体:任何能够访问您的 X 套接字并读取此文件的人都可以与您的显示器对话。仅将其交给真正需要它的环境,并且不要将副本留在共享计算机上。这个技巧只是一个更大设置的一小部分——我用它来将 X 转发到非特权 LXC 容器中,我在《使用 LXC 增强 x11 应用程序安全性》中详细写了它。在《黑客新闻》上进行了讨论。
这篇文章对您有帮助吗?
订阅66必读
每日精选科技资讯,直达你的邮箱