feat: add instance-specific config

[reddevillg]

Add support for defining custom mounts in runtime configuration files.

Run with --instance will apply instance-specific runtime configurations and run in an isolate container environment.

[deepin-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: reddevillg

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[gemini-code-assist]

Code Review

This pull request introduces support for container instances and custom mounts within the Linglong runtime. Key changes include updates to the API schema, the addition of an --instance CLI flag, and enhanced runtime configuration merging logic to handle instance-specific overrides and mount points. Feedback highlights a violation of the noexcept contract in ResolveOptions methods due to potential memory allocations and a semantic issue where optional mount options were not being correctly preserved as nullopt when passed to the OCI specification.

[codecov]

Codecov Report

❌ Patch coverage is 21.90476% with 82 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...inglong/src/linglong/runtime/container_builder.cpp	0.00%	36 Missing ⚠️
libs/linglong/src/linglong/runtime/run_context.cpp	43.33%	13 Missing and 4 partials ⚠️
libs/utils/src/linglong/utils/runtime_config.cpp	40.00%	0 Missing and 15 partials ⚠️
libs/linglong/src/linglong/cli/cli.cpp	0.00%	11 Missing ⚠️
apps/ll-cli/src/main.cpp	0.00%	3 Missing ⚠️

Files with missing lines	Coverage Δ
libs/linglong/src/linglong/cli/cli.h	8.33% <ø> (ø)
libs/linglong/src/linglong/runtime/run_context.h	76.92% <ø> (ø)
apps/ll-cli/src/main.cpp	0.00% <0.00%> (ø)
libs/linglong/src/linglong/cli/cli.cpp	1.77% <0.00%> (-0.01%)	⬇️
libs/utils/src/linglong/utils/runtime_config.cpp	39.17% <40.00%> (+13.49%)	⬆️
libs/linglong/src/linglong/runtime/run_context.cpp	15.51% <43.33%> (+1.48%)	⬆️
...inglong/src/linglong/runtime/container_builder.cpp	7.73% <0.00%> (-0.86%)	⬇️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[deepin-ci-robot]

deepin pr auto review

这份代码变更主要实现了容器运行时的“实例化”配置与自定义挂载功能。通过引入 instance 字段和 mounts 数组，用户可以针对同一个应用加载不同的配置（如开发环境、生产环境），并在容器内挂载自定义的目录或文件。

整体来看，代码结构清晰，逻辑连贯，并包含了较为完善的单元测试。但在安全性、代码质量和逻辑严谨性方面，还有以下需要关注和改进的地方：

1. 代码安全

1.1 宿主机路径遍历漏洞
在 container_builder.cpp 中，normalizeContainerRootfs 函数对 destination 进行了路径遍历检查，这非常好。但是，完全没有对 source 进行校验。
如果用户可以控制配置文件或 CLI 参数，他们可能会指定类似 source: "/etc/shadow" 或 source: "/" 的挂载，从而将宿主机的敏感文件完整地暴露给容器，造成严重的信息泄露或提权风险。

• 改进建议：增加对 source 路径的安全校验。可以维护一个黑名单（如禁止挂载 /etc, /root, /proc, /sys 等），或者要求挂载源必须在特定的允许目录下（如用户的 Home 目录或特定的共享数据目录）。

1.2 潜在的符号链接攻击
isPathInRootfs 使用了 lexically_normal，这只能处理路径中的 ../ 字符串，但无法解析文件系统上的软链接。如果 rootfs 或 destPath 中包含符号链接，其实际路径可能会逃逸出 rootfs。

• 改进建议：在路径校验前，考虑使用 std::filesystem::canonical 或 std::filesystem::weakly_canonical 解析真实的路径，再进行包含性检查。

2. 代码逻辑

2.1 ensureMountSrcType 中的错误处理缺失
在 run_context.cpp 的 ensureMountSrcType 中，调用了 std::filesystem::exists 和 is_directory，但忽略了可能产生的 std::error_code。
如果 source 路径是一个无权限访问的路径，或者是一个损坏的符号链接，ec 会被赋值，此时 exists(srcPath, ec) 会返回 false，代码会将其 srcType 设为 std::nullopt，这可能会掩盖真实的权限错误，导致挂载静默失败。

• 改进建议：检查 ec，如果出现权限错误（如 EACCES），应当抛出异常或返回错误提示，而不是简单地当作不存在处理。

2.2 JSON Schema 中的 src_type 语义模糊
在 Mount 结构中，type 表示文件系统类型（如 bind），而 src_type 表示源路径是文件还是目录（file / dir）。但在 container_builder.cpp 中，只有当 m.srcType 存在时才会去创建挂载点。
如果用户在 JSON 中省略了 src_type，且 ensureMountSrcType 因为权限问题未能自动推断，那么挂载点将不会被创建，后续容器运行时挂载可能会失败。

• 改进建议：在 normalizeContainerRootfs 中，如果 srcType 为空，应该有一个 fallback 逻辑（比如默认按目录处理，或者尝试通过其他方式探测），而不是直接 continue 跳过。

2.3 instances 递归合并可能导致的非预期覆盖
在 runtime_config.cpp 中，MergeRuntimeConfig 实现了 instances 的递归合并。当两个配置都有 instances["dev"] 时，会合并其内部属性。
但是，如果用户在全局配置了 instances.dev.env = {A: 1}，在局部配置了 instances.dev.env = {B: 2}，合并结果是 {A:1, B:2}。这在某些场景下是好的，但如果用户希望局部配置完全覆盖全局的 env 而不是合并，当前逻辑无法实现。

• 改进建议：确认业务需求，是否需要支持“覆盖语义”。如果需要，可能要在 JSON Schema 中引入类似 strategy 的字段，或者明确规定 map 类型是追加合并，array 类型也是追加合并（当前 mounts 是追加，可能导致重复挂载项）。

3. 代码质量

3.1 循环依赖风险
在 run_context.h 中，引入了 linglong/cli/cli.h 的前向声明，并在 run_context.cpp 中包含了完整的 linglong/cli/cli.h。
cli.h 通常属于上层业务逻辑，而 run_context 属于底层运行时核心。底层依赖上层的结构体会导致模块耦合，容易引发循环依赖。

• 改进建议：将 cli::RunOptions 中与底层运行时相关的字段（如 base, runtime, extensions, instance）提取到一个独立的、无业务依赖的 DTO（Data Transfer Object）结构体中（例如 RunContextRequest），让 CLI 层负责将 RunOptions 转换为 RunContextRequest，再传给 ResolveOptions。

3.2 C++ 结构体初始化的健壮性
在 run_context_test.cpp 中大量使用了 C++20 的指定初始化器：

api::types::v1::Mount{ .destination = "/tmp/a", .source = "/host/a", .type = "bind" }

这很现代，但 Mount 结构体定义在 Mount.hpp 中顺序为：destination, options, source, srcType, type。
初始化列表的顺序与声明顺序不一致（跳过了 options 和 srcType）。虽然 C++ 语法允许跳过（它们会被值初始化为空），但如果不小心把顺序写反了，编译器不会报错，容易埋下隐患。

• 改进建议：建议将 Mount 结构体的成员按必选到可选的顺序排列，并且将 type 放在 source 之后，保持结构紧凑和直觉性：

  struct Mount {
      std::string destination;
      std::string source;
      std::string type;
      std::optional<std::vector<std::string>> options;
      std::optional<std::string> srcType;
  };

3.3 std::ofstream 的隐式创建与错误处理
在 container_builder.cpp 中：

std::ofstream(dest) << "";

这行代码尝试创建空文件，但没有检查文件是否创建成功。如果磁盘满或权限不足，这里会静默失败。

• 改进建议：检查 std::ofstream 的状态：

  std::ofstream ofs(dest);
  if (!ofs) {
      LogW("failed to create file for mount point {}: ...", dest, "...");
      continue;
  }

4. 代码性能

4.1 不必要的深拷贝
在 runtime_config.cpp 中：

auto instanceConfig = std::move((*merged.instances)[instance]);
std::vector<RuntimeConfigure> toMerge;
toMerge.emplace_back(std::move(merged));
toMerge.emplace_back(std::move(instanceConfig));
merged = MergeRuntimeConfig(toMerge);

这里将 merged 整个移动到 toMerge 中，然后调用递归合并。MergeRuntimeConfig 接受的是 const std::vector<RuntimeConfigure>&，这意味着在合并时，merged 的所有内容（包括不需要合并的 mounts, env 等）都会被重新遍历和拷贝一次。

• 改进建议：由于我们只需要将 instanceConfig 的属性覆盖/追加到 merged 上，可以直接就地修改，避免构造临时 vector 和全量重新合并：

  if (!instance.empty() && merged.instances && ...) {
      auto instanceConfig = std::move((*merged.instances)[instance]);
      // 就地合并逻辑，例如：
      if (instanceConfig.mounts) {
          if (!merged.mounts) merged.mounts = instanceConfig.mounts;
          else merged.mounts->insert(...);
      }
      // ... 其他字段合并
  }
  merged.instances = std::nullopt;

总结

此 PR 的功能实现很完整，但最严重的问题是挂载源路径未做安全校验，这在容器场景下是高危漏洞。建议优先修复安全问题，其次优化 ensureMountSrcType 的错误处理，最后再考虑重构模块依赖和性能优化点。