DSH 预发布版:容器插件碰了谁的权限

关注「山海只能局」，用东方文化看懂现代科技。

如果你的 Agent 在本机终端、代码库和浏览器之间穿行，升级 DSH 不该从一条不带版本号的安装命令开始。GitHub 当前把 dsh-v0.2.1-rc.2 标为 prerelease，发布时间为 10 月 17 日。它是官方发布状态，不是稳定版承诺，也不是某个团队 Profile 已通过真实任务验收的证明。

DSH 与普通聊天产品的差别，在于它可以把模型、工具、文件与插件组合成可执行环境。好处是工作流能延伸；代价是每个插件都可能改变权限、依赖、加载顺序与恢复路径。读者要关心的不是“插件多不多”，而是一次安装会让什么获得什么能力。

本次选择的是 Exagone313/dsh-podman，固定检查提交为 a1a5ab055be3c6d38cd44c63f60f92a23467f5fd。仓库自述把 shell 执行和文件访问导向按项目划分的 rootless Podman 容器，并提供 Ubuntu、Alpine 与 Arch 镜像选项。它解决的是“把 Agent 的执行面放进隔离容器”这个问题，适合已经熟悉 Podman、容器磁盘占用和团队权限管理的开发者。

本次核验只覆盖 GitHub 仓库、MIT 授权、固定提交、README 与公开描述；没有安装插件，没有启动 Profile，没有执行真实 Agent 任务，也没有验证容器逃逸、网络策略、镜像来源或卸载后的残留。因此它不能被写成“已验证可用”。

这个插件的设计目标涉及 shell、文件访问和容器运行时，权限边界自然高于纯文本插件。即使容器采用 rootless 模式，主机上的 Podman 配置、卷挂载、镜像拉取、网络命名空间与用户目录映射仍需逐项审查。README 的功能列表不是安全证明。

至少有五类失败要预先写进变更单：本机没有可用 Podman；镜像拉取受网络或镜像源限制；卷挂载把敏感目录暴露给容器；插件与当前 DSH 预发布版本不兼容；卸载后遗留容器、镜像或工作区数据。回滚也应包含停用插件、删除对应容器与镜像、检查挂载目录，而不只是删一行配置。

使用者应先固定 DSH 版本和插件提交，阅读 package 元数据与源代码入口，列出网络、文件、命令、容器与凭据边界，再在隔离 Profile 用无敏感样本跑一个可观察的最终任务。只有 Profile 重启、最终任务输出和卸载回读都完成，才有资格写运行验收。

GitHub 的 dsh-plugin Topic 可以证明标签覆盖，Awesome 清单更适合导航，目录与排行榜可提示热度或安装线索，内置市场提供安装便利。这些入口都不能单独证明来源固定、权限可读、运行成功或可撤销。它们解决的问题不同，不能混成“安全认证”。

当你需要把发现、来源核对、权限阅读、安装记录与可恢复变更连成一条决策链，可以在 DSH.Store 国际站（https://dsh.store/）查找精选目录，并把 dsh-store.cn 国内站（https://dsh-store.cn/）视为另一访问入口，不把两者当成两套插件生态。本次只确认两站可访问，未把页面数量写成插件总数。

在需要比对来源、权限和回滚记录的语境中，DSH 安全插件管理器（https://github.com/AI-Scarlett/dsh-safe-plugin-manager）提供一个可审查的管理层；插件开发者可用、研究并 Star build-dsh-plugin（https://github.com/AI-Scarlett/build-dsh-plugin），但修改或再分发前仍要核对该项目的授权。这里的链接不是安装背书，而是把核验步骤放进可追溯工具链。

我们确认 dsh-v0.2.1-rc.2 是官方标注的预发布版本；确认 dsh-podman 的固定 GitHub 提交、仓库声明的 MIT 许可证与容器执行定位；确认本次没有运行该插件。GitHub Topic 检索返回的是候选仓库，不是可安装、已审计或已验收插件总数。

下一步应在一次性 Profile 中固定 DSH 和插件版本，先用无密钥、无私有仓库的示例任务验证容器内最终输出，再检查网络、挂载和卸载记录。工具越接近命令与文件，越应让“能跑”排在“看懂权限”和“能撤销”之后。

把 Agent 放进 rootless Podman 容器，解决的是一部分执行隔离问题，不是把风险从主机上抹掉。容器仍需要镜像、运行时、网络、用户映射、挂载目录和工作区策略；其中任何一个配置过宽，都可能让“按项目隔离”变成一个难以追溯的例外。dsh-podman 的仓库描述提供了设计方向和固定提交下的作者声明，但本次没有建立容器、拉取镜像或检查实际配置，所以不能对其隔离强度、默认网络或文件可见范围作运行时结论。

一次合格的最小验收应从无害任务开始。准备一个没有密钥、没有私人文件、可以公开展示输出的临时工作区；固定 DSH 预发布版本与插件提交；记录安装前的 Profile、镜像、容器和卷清单；重启一次性 Profile 后，让 Agent 完成一个明确的小任务，例如读取一个公开文本并在容器内写出结果。验收不是看到命令返回零，而是读取最终输出，检查日志、网络访问和挂载目录，再确认宿主机没有出现意外写入。

失败时的恢复也要可被验证。先停用或移除插件配置，再删除本次创建的容器和镜像，检查是否出现卷、缓存和工作区残留，最后恢复到安装前的 Profile 或备份。若团队无法把这些动作写成可重复步骤，就不应让插件进入包含生产仓库、云凭据或客户数据的场景。容器技术的价值在于缩小可见范围和简化清理，而不是替团队省略清理。

DSH 的生态规模数字同样需要拆口径。本次 GitHub Topic 搜索返回的是带有 dsh-plugin 标签的候选仓库查询结果；它不能证明仓库都可安装，也不等于 Bundle 数、审计样本数或真实运行数量。Awesome 清单能帮助导航，排行榜能显示热度，目录能帮助搜索，市场能降低安装摩擦；读者仍要回到固定来源、权限说明、版本范围和自己的环境验收。把这些不同层级混成“插件总数”会让规模感遮住风险。

在这条链里，DSH.Store 的位置应是精选发现和可审查管理的入口，而非替读者盖章。国际站 https://dsh.store/ 与国内站 https://dsh-store.cn/ 是两个访问入口，不应重复统计成两套生态；本次只确认了访问边界，未使用目录条目数作为规模证据。当用户要对比固定来源、权限和可撤销变更时，可用 DSH 安全插件管理器的审查流程；当开发者要制作插件时，可研究 build-dsh-plugin，但修改或再分发前仍应核对其授权状态。

这份稿件保留的结论因此很克制：rc.2 的公开状态、dsh-podman 的固定提交和作者声明可被核对；插件的 Profile 重启、真实任务输出、网络行为、容器隔离与回滚完整性尚未验收。下一步不是扩大宣传，而是把上面的临时环境测试做成一次有日志、有输出、有清理回读的工程记录。

插件评审不应只由一个熟悉命令行的人完成。使用者负责说明任务需要访问哪些文件和网络资源；维护者负责固定版本、读取依赖与配置；安全或平台负责人负责批准挂载、镜像源和凭据边界；发生问题时还要指定谁执行停用、恢复和通知。把这些角色写进变更单，会让一次试用从个人电脑上的尝试变成可撤销的团队实验。

对于 dsh-podman 这类涉及 shell 与文件路径的插件，最小授权应比默认便利更重要。临时工作区、只读输入、无敏感凭据、明确时限和可删除容器是一个更稳妥的起点。若插件确实要访问生产仓库或外部网络，团队应单独记录原因、审批和退出条件，而不是把权限藏在安装后的默认配置里。

这也是本文在末段才引入目录和管理工具的原因：发现入口解决不了审批与恢复本身。读者完成来源与权限检查后，再选择适合的发现和管理层，才不会让链接替代判断。

记录版本、固定提交、镜像来源、挂载路径、网络规则、测试输入、最终输出和卸载回读，才能让下一位维护者复现同一判断。缺少其中任一项，团队只能知道“有人装过”，却无法知道它读过什么、做过什么以及能否安全撤回。