• 你机器 2026-07-06 装机那天的 base system 提交里，所有普通文件就已经是 -00777 —— 说明安装器/镜像本身就是这套逻辑产出的；
• 缺陷所在的 deepin-immutable-ctl 现在装的是 1.0.39，就是仓库里的最新版（没有可升级的修复版）；
• 昨天我用它跑了一次 admin deploy：可写层里明明是 4755 / 640，写进提交仍然是 0777 —— 直接复现。

所以同版本重装 = 把同一个坏底子再装一遍，开机 5 分钟后 cleanup 一跑，权限又回 0777。除非 Deepin 发布修复版。

② 重装成"非不可变"的 Deepin，或换普通发行版（Ubuntu / Debian / Fedora）→ 会解决

这个问题的根只有两条：不可变系统写提交时丢权限 + 系统目录被叠成 overlay。普通安装没有这两件事，chmod/setuid 天生正常，也就没有这套"权限被周期性打回"的怪象。

感谢楼主把现象和复现思路整理出来，这类权限问题确实值得认真核实。我用Deepin 虚拟机安装了帖子提到的 1.0.39，测试了普通部署、修改层刷新，并分别重启。/usr 和 /etc 中的 0640、4755、2755 等权限都保留正常，sudo、passwd 也没有丢失特殊权限。因此，目前不能说这个版本每次部署都会把文件变成 0777。

不过，对照实验发现了另一种可能：这类 OSTree 仓库中的部分部署文件和仓库对象是硬链接，可以理解成同一个文件的两个名字。如果直接修改其中一处的权限，另一处也会一起改变，连旧提交查询出来的权限都会变。之后即使把权限正确的文件重新提交，也可能继续使用已经损坏的对象，新提交仍显示 0777；相同文件提交到干净仓库则正常。

看看能否详细说明下这个问题的具体影响，或者让DSH再继续分析下？

一、完整报告

Deepin 不可变系统权限异常核查报告

核查日期：2026 年 10 月 7 日
**核查对象：**论坛帖子 《DSH 发现的权限问题，请管理员核实》
**核查方式：**在本机已有 Deepin 虚拟机中验证正常部署流程，并进行隔离对照实验。

1. 核心结论

本次未复现“deepin-immutable-ctl 1.0.39 在正常部署过程中，将普通文件权限统一写成 0777”的问题。

在测试虚拟机上，admin deploy、admin deploy --refresh 以及分别启动新部署后，测试文件的 0600、0640、0755、2755、4755 权限均得到保留。

与此同时，隔离实验确认了另一种能够产生帖子关键现象的机制：

当 bare OSTree 仓库与部署文件通过硬链接共享文件时，直接修改部署文件的权限，可能同时损坏仓库对象。此后，历史提交会读出错误权限；即使重新提交权限正确的文件，新提交也可能复用这个损坏对象，继续显示错误权限。

因此，帖子中的观察值得认真调查，但目前不能据此认定：

• 正常部署程序必然丢失权限；
• 安装镜像从一开始就存在同样的问题；
• 所有相同版本的安装都会受影响；
• 同版本重装必然无效。

本次验证找到的是一个已证实的候选故障机制，不是论坛原机器已经查明的实际根因。

---

2. 帖子描述的现象与可能影响

按帖子描述，部分普通文件权限发生了以下变化：

4755 → 0777
0640 → 0777

两种变化的含义不同：

权限变化	主要影响
4755 → 0777	丢失 setuid 标志，同时增加其他用户的写权限
0640 → 0777	原本受限制的文件变成所有人可读、可写、可执行

如果 sudo、passwd 等依赖 setuid 的程序确实发生第一种变化，普通用户执行时可能无法取得所需权限，出现提权、修改密码等功能异常。

如果受限制的文件发生第二种变化，则可能造成信息暴露；是否能够修改文件，还取决于挂载是否只读、目录权限以及运行中的叠加视图等条件。

帖子描述了功能故障，但目前没有证据证明已经发生信息泄露、恶意篡改或入侵。安全风险和已发生的安全事件应当分开表述。

---

3. 测试环境及范围

项目	实际环境
虚拟机	VirtualBox，deepin V25
操作系统	Deepin 25.1.1
内核	6.18.34-amd64-desktop-rolling
原工具版本	deepin-immutable-ctl 1.0.31
重点验证版本	官方仓库 deepin-immutable-ctl 1.0.39
OSTree/libostree	2024.6-1deepin10
仓库模式	系统、持久数据两个仓库均为 bare
文件系统结构	/usr、/etc 使用 OverlayFS

实验前建立了恢复快照。测试使用无害文本文件，没有修改真实 sudo 等程序的权限，也没有对真实系统仓库中的共享文件进行破坏性操作。

为避免自动任务干扰，实验期间暂停了 cleanup timer。

---

4. 正常部署流程验证

在 /usr 和 /etc 创建五组权限探针，执行 1.0.39 的真实部署命令，依次检查：

1. 提交前的运行视图；
2. 合并暂存文件；
3. 新 OSTree commit；
4. 部署目录；
5. 重启后实际运行视图。

结果如下，两处测试文件均一致：

普通文件初始权限	合并暂存	新 commit	部署目录	重启后
0600	0600	0600	0600	0600
0640	0640	0640	0640	0640
0755	0755	0755	0755	0755
2755	2755	2755	2755	2755
4755	4755	4755	4755	4755

其他检查结果：

• 测试目录的 0750 权限得到保留。
• 测试文件的用户扩展属性得到保留。
• 符号链接显示 l00777，属于正常情况，不是普通文件权限异常。
• sudo、passwd 保持 4755。
• shadow 保持 0640。
• 重启后，探针没有残留在新旧修改层中，实际使用的是 data checkout 的文件。

最后一点尤其重要：正确权限不是被旧的可写副本暂时遮挡出来的，而是新部署中的文件本身就正确。

随后执行 admin deploy --refresh，检查新提交和部署目录，并再次重启，权限仍全部正确。

普通部署之后、refresh 之前，对两个真实仓库进行了 ostree fsck 检查，均通过，未发现对象损坏。

这些结果可以反驳“该版本在这种架构下每次部署必然改坏权限”，但不能证明所有配置、所有操作路径都没有问题。

---

5. 隔离实验确认的故障机制

5.1 修改硬链接部署文件，会影响仓库对象

在独立的临时 bare 仓库中：

1. 将权限为 4755 的文件正常提交。
2. 使用硬链接方式 checkout。
3. 只将 checkout 中的文件改为 0777。
4. 再次查询原来的旧 commit。

查询结果从：

-04755 ... /probe

变为：

-00777 ... /probe

旧 commit ID 没有改变。完整性检查报告：

Corrupted file object; checksum expected=... actual=...

原因是：checkout 文件和仓库对象共享同一个 inode。修改其中一个名字对应的文件属性，也会影响另一个。

这里并不是“旧 commit 被重新提交了”，而是它引用的底层对象被原地改坏了。

因此：

今天查询安装当天的 commit 得到错误权限，不能单独证明安装当天的权限就错误。

5.2 正确输入重新提交，也可能继续得到错误结果

原始输入文件没有被修改，仍为 4755。将它重新提交到上述已损坏仓库，新 commit 仍显示 0777。

对照结果：

提交条件	查询结果
正确输入，提交到已损坏仓库	0777
相同正确输入，提交到干净仓库	4755
改变文件内容，提交到已损坏仓库	4755

这说明，提交过程可能复用已经存在的损坏对象，而不是重新写入并修复它。

所以：

“输入权限正确、新 commit 权限错误”，也不足以单独证明本次合并或提交程序丢失权限。

但原机器是否发生过共享文件修改，以及由哪个命令、脚本或程序触发，仍然未知。不能据此说明有误操作，也不能直接认定某个程序缺陷已经定位。

---

6. OSTree 与 OverlayFS 分别起了什么作用？

应当将三件事分开：

机制	作用及验证结果
OverlayFS copy-up	独立实验中保留 0640、2755、4755，未出现统一转换为 0777
OverlayFS 上下层遮挡	正确上层可以遮住错误下层；上层撤掉后，错误可能暴露
bare OSTree 硬链接共享	原地修改共享文件属性，可能污染仓库对象及引用它的历史部署

一条可能的故障链是：

下层文件或仓库对象被原地改坏
        ↓
历史提交查询也显示错误权限
        ↓
正确的 overlay 上层暂时遮住错误
        ↓
重新提交时复用损坏对象
        ↓
清理修改层或启动新部署后，错误暴露

这条链在机制上可以解释帖子，但原机器是否经历了这条链尚未确认。

OverlayFS 可以解释故障何时暴露，不能因此认定它是权限最初变坏的原因。OSTree 与 OverlayFS 混用本身，也不是足够的根因解释。

---

7. cleanup timer 的判断

本机 cleanup 服务执行：

deepin-immutable-ctl admin deploy --auto-refresh --wait-boot

它不是无条件每次都创建新提交。

实验初始旧修改层约为 19 MiB，默认自动刷新阈值为 200 MiB。手动启动真实 cleanup 服务后：

• 服务执行成功；
• 前后部署状态没有变化。

因此，“每次开机五分钟必然重新写坏权限”这个绝对判断不成立。

这不代表 cleanup 在其他条件下不会执行合并，而是说明计时器触发、实际合并、创建部署、启动新部署，是不同的步骤，不能混为一谈。

---

8. 主要判断的评价

帖子判断	本次核查结论
正常 deploy 一律把普通文件写成 0777	本机未复现，现有实验不支持普遍性结论
上层正确文件能暂时遮住下层错误	机制成立
清理或重启后可能暴露下层错误	有条件成立
安装当天 commit 当前异常，证明 ISO 天生异常	证据不足，需排除后续对象污染
正确输入产生错误新 commit，证明提交程序丢权限	不充分，损坏对象复用也能解释
修改层很小，证明整个 /usr 都回落到 0777	不成立，需逐文件核对其他下层
同版本重装必然无效	未被证明
五分钟 cleanup 每次必然破坏权限	本机服务行为不支持这种绝对表述

辛苦管理员了，我因为后面一直被提示有这个问题。后来重新出厂初始化系统了，现在也无法复现了。感谢 。

不一定是 deepin 导致的......如果在其他硬盘里安装过 OpenHarmony 也有可能导致这个问题（比如深开鸿 x86 镜像）。

---

OpenHarmony 默认的磁盘管理进程会自动尝试挂载外部可移动存储设备上已知的文件系统类型，挂载 ext4 的时候为了保证可读写，会直接递归 chmod 0777 来着......然而有可能把本机的 SATA 硬盘认为是外置存储设备，一起改掉