关于 UOS 开发者模式的两种判断方式

在 UOS 应用适配过程中有时需要判断系统是否已经开启开发者模式。常见的实现思路有两种检查系统中的开发者模式标志文件或者通过 DBus 接口查询。下面分别记录这两种方式的实现以及使用时需要注意的地方。先判断当前系统是不是 UOS无论采用哪种方式都可以先读取/etc/os-release根据其中的ID判断当前系统。bool isUosSystem() { const QString path /etc/os-release; if (!QFile::exists(path)) { return false; } QSettings releaseFile( path, QSettings::IniFormat ); const QString systemId releaseFile.value(ID).toString(); return systemId.contains( uos, Qt::CaseInsensitive ); }/etc/os-release是 Linux 中常见的系统信息文件。这里只读取ID字段不需要根据系统显示名称或者版本字符串进行判断。方式一检查开发者模式标志文件UOS 开启开发者模式后可以通过下面的标志文件判断状态/var/lib/deepin/developer-mode/enabled使用 Qt 判断时代码比较简单bool isDeveloperModeEnabledByFile() { if (!isUosSystem()) { return false; } return QFile::exists( /var/lib/deepin/developer-mode/enabled ); }这种方式本质上是判断标志文件是否存在并不需要读取文件内容。它的特点是实现简单不需要创建 DBus 对象也不依赖目标服务当前是否正常响应。需要注意的是代码会依赖具体文件路径因此在不同系统版本或不同发行版中使用时要确认对应路径是否一致。需要额外注意的是在实际签名过程中程序直接访问这个路径曾被签名检测判定为风险操作并导致签名被拒。使用文件判断方式时最好提前确认目标系统的签名规则。方式二通过 DBus 接口查询另一种方式是连接 System Bus通过系统服务查询开发者模式。接口信息如下Service: com.deepin.sync.Helper Path: /com/deepin/sync/Helper Interface: com.deepin.sync.Helper Method: IsDeveloperMode使用 Qt DBus 调用的示例bool isDeveloperModeEnabledByDBus() { QDBusConnection bus QDBusConnection::systemBus(); if (!bus.isConnected()) { qWarning() System Bus is not connected; return false; } QDBusInterface iface( com.deepin.sync.Helper, /com/deepin/sync/Helper, com.deepin.sync.Helper, bus ); if (!iface.isValid()) { qWarning() Invalid DBus interface: bus.lastError().message(); return false; } QDBusReplybool reply iface.call(IsDeveloperMode); if (!reply.isValid()) { qWarning() Query failed: reply.error().message(); return false; } return reply.value(); }调用过程可以分成三步连接系统总线QDBusConnection::systemBus()创建com.deepin.sync.Helper接口对象调用IsDeveloperMode并读取布尔返回值。使用这种方式时除了方法返回的开发者模式状态还需要处理 System Bus 未连接、服务不存在、接口无效以及调用失败等情况。两种方式的差异标志文件方式的代码更少调用过程也比较直接但会依赖固定的文件路径。DBus 方式不需要了解状态文件的具体保存形式不过运行时依赖 System Bus 和对应的系统服务。如果服务没有启动或者接口不可用就无法得到有效结果。两种方式可以简单归纳为已知系统版本和标志文件路径时可以使用文件判断希望通过系统服务获取状态时可以使用 DBus文件方案要处理路径变化DBus 方案要处理服务和调用异常两种方案都建议在无法确认状态时返回false。对 UOS 拒签原因的推测下面这部分只是根据现象做的技术推测并不是 UOS 官方给出的结论。准确原因仍应以签名审核结果或官方反馈为准。从现象来看使用QFile::exists()检查开发者模式标志文件时程序会被识别为存在风险操作最终导致签名被拒。可能有以下几个原因。第一敏感字符串和路径访问可能触发同一类检测规则。当时的检测反馈截图中命中了developer-mode相关内容。标志文件路径会以字符串常量保存在编译产物中签名工具可能在静态扫描时识别到该字符串。同时QFile::exists()虽然不会读取或修改文件内容底层仍会查询/var/lib/deepin/developer-mode/下文件的元数据。因此拒签既可能由敏感字符串触发也可能与对系统敏感路径的实际访问有关。第二检测规则可能更关注访问对象而不是访问目的。签名检测通常无法仅凭一次文件存在性判断准确推断业务目的因此可能采用相对保守的规则只要程序引用或访问特定系统目录就将其标记出来而不会因为操作是只读的就自动放行。第三系统可能更希望应用通过服务接口获取状态。开发者模式可以通过com.deepin.sync.Helper的IsDeveloperMode查询。和直接检查内部文件相比DBus 接口的调用边界更明确系统服务也可以统一处理状态读取和权限控制。