Android 那我不懂了，虽然是 Linux 但确实有一些区别

哦，是说 Android 上的 netns？还以为是 arch

通常客户端不重要，重要的是服务（

那就需要 NDP 代理之类的方案了

veth 等于是主机路由模式吧

不知道是不是修了 shell 注入

可以，比如桥接就行

这得应用程序自己做触屏支持吧

不要拿应试思维来学

wiki 和面试没半点关系（

没问题的时候去读这些干啥（

不至于，有问题解决问题就行

总体上应该是 arch wiki 内容多一些，不过一些涉及编译什么的那还是 gentoo wiki 更详细

别的软件都没问题那就是出问题的那个软件的问题呗（ 去提个 issue？

https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#PrivateMounts=

这是哪页手册？

你要不想想你在说什么（

没试过，但应该需要特权才能看

盲猜是和 ooxml 一样表面公开，实际上按公开实现并不能与微软的实现互操作（

哦只是 tg 号

（原来 q234rty 之前没在这个群吗

杞人忧天也不管用

发生了再说

信创平台也是 Linux。另外就不要过度揣测没有发生的事情了

mkinitcpio 不是已经支持 ukify 了么

我刚也遇到这个 bug 了

只能说庆幸暂时还没有这样的检测

是这样的。不过也就是猫鼠游戏，挂载表也可以伪造

虚拟机比 namespace 暴露的信息多得多

实际上虚拟机检测反而比 namespace 沙盒检测成熟多了

而且用户空间网络栈我觉得那才是太重了，功能不如内核网络栈完善，性能也不好

你现在也可以看一眼 pacman.log

当然修系统兜底还是常备 archiso 比较好

所以从源头避免问题是最好的

我见过的大部分此类内核和 initramfs 问题应该都是不认真看 pacman 报错导致的，还有一部分是回滚快照导致的，这两种占了 99%

是的，不用用户空间网络栈那只能这样

我没设密码，等于是锁住的

那你 archiso 进去以后看看 /mnt/var/log/pacman.log 吧

不看输出的话就和自动跑没区别了

手动的意义就是仔细看输出提示，不论是报错还是提示都可能需要手动介入处理

你当时有没有仔细看 pacman 是否有报错

* swapfile 本身经过了一层 fs 层就增加了复杂性，容易出问题

休眠 image 的压缩算法可以试试换成 lz4

swapfile 本身经过了一层 fs 层就增加的复杂性，容易出问题

是这样的

systemd 不能探测 swapfile on btrfs 的偏移量吗？虽然我没这么用过，但不应该啊（

之前你是两个参数都没有还是有其中一个

* 看一下 /proc/cmdline

看一下/proc/cmdline

hibernate 不起作用的话这样会出事的，系统会自动唤醒然后睡不着

所以你就还没尝试它吗（

让提问者自己答（

systemctl hibernate 是什么效果

我反正是觉得 btrfs 配合 swap 分区省事一些，毕竟 btrfs 尾部伸缩起来也比较方便

我以前也这么做然后被群 systemd 开发者批评了（

在 systemd 系统上不应该绕过 systemd 触发睡眠或休眠

文件系统和这里描述的事情无关吧。没有理由不能用（

但有一说一，这仍然可能存在 shell 注入

那至少我觉得这不算彻底修复（

那之前已经发出去的呢（

还有昨天爆出来那个 shell 注入漏洞，据说是在服务器侧修复了，但一个客户端点击文件触发的漏洞如何在服务器修复？我只能盲猜客户端本身有点击文件时发送网络请求，并可以被服务器拒绝的逻辑

还没检测 namespace 就偷着乐吧（

这个讨论也不局限于 flatpak

至少目前 Linux 桌面上的闭源软件似乎还没有这么做的

如果闭源程序铁了心要检测沙盒并拒绝运行的话，那就是没有很好的办法的

所以就先不考虑动态授权喽，考虑静态配置的权限

应用程序沙箱应该是什么样，可以看看 android app。在“正常情况”下，一个恶意的 app 也不能任意读取其它 app 的数据，也不能获取 root 权限

这和应用程序沙箱不是一回事，是不同的用途

否则只能重启应用程序生效

动态授权必须要单独设计 api

那个依赖 ebpf 吧

这都是 flatpak 限制太宽松，并不是不可解决的

我觉得限制局域网的话 mdns 一起被限制应该是预期的？

mdns 吗

嗯……确实。这个我觉得也不难，给每个应用程序一个 dns proxy，然后在沙盒里 bind 进一个 resolv.conf 和 nsswitch.conf

其实除了能不能直接与内核对话之外没什么区别

为什么要涉及 dns（

我觉得限制 localhost 和局域网应该对绝大部分程序来说不会 break

* 所以浏览器也会使用 namespace 作为纵深防御

使用浏览器也会使用 namespace 作为纵深防御

是这样的

这就是个安全边界的问题，应用程序沙箱必然要信任内核作为安全边界

为什么不可能，因为应用程序能调用内核？

只是具体的攻击面大小不同

因为本质上是一样的

还是那句话，如果你在运行每一条 js 之前也防范那我不说什么

* 自己实现应该是可行的，xwayland-run 做的事情不多

应该是可行的，xwayland-run 做的事情不多

应用程序沙箱也可以，依靠 namespace 来保证，最大可以把程序限制到只能与内核对话

为什么要自己实现呢

只能说 native 应用程序攻击面肯定大了很多，因为能直接调用内核，不做限制的话还可以 IPC。但做好限制的话还是能好不少的

js 同理

应用程序沙箱就不能有吗（

如果你的浏览器禁用 js 的话，那我认同这句话

我觉得通常也没必要分那么细，大多数需求应该就限制一下 localhost 和局域网就足够了

现在做得不好不代表就该什么都不做了

限制网络访问吧，目前 netns 里如果不用用户空间网络栈，就没法在非特权的情况下访问网络

https://github.com/flatpak/flatpak/issues/1202#issuecomment-3883678901 https://www.scabala.it/blog/linux-application-firewall/

不过说是已经修了？但我也不懂这是怎么修的 https://github.com/systemd/systemd/pull/38351

https://github.com/systemd/systemd/issues/37590