Wekan Snap 安装的权限加固：将 snap 命令与数据目录限制为仅 root 用户访问-二趣网

Wekan Snap 安装的权限加固：将 snap 命令与数据目录限制为仅 root 用户访问

【免费下载链接】wekanThe Open Source kanban, built with Meteor. GitHub issues/PRs are only for FLOSS Developers, not for support, support is at https://wekan.fi/commercial-support/ . PR source translation to imports/i18n/data/en.i18n.json, other translations at https://app.transifex.com/wekan/wekan项目地址: https://gitcode.com/GitHub_Trending/we/wekan

导读

当一台服务器上既有 root 管理员、又有只拥有普通账号的协作者登录时，系统自带的snap命令默认对所有用户可执行，任何人都可能通过它查看甚至篡改 snap 软件包的运行状态。本篇文章以 Wekan 的 Snap 部署形态为例，给出了一套完整的权限收紧方案：先通过snap set core refresh.schedule固定自动更新窗口，再借助 cron 任务在每次更新完成后用chmod把/usr/bin/snap与/var/snap重新锁定为仅 root 可读写。读完本文，你将掌握在共享主机上安全部署、维护 Wekan Snap 实例的完整命令流程与底层原理。

适用场景：为什么要把 snap 限制为仅 root

Wekan 是一个基于 Meteor 构建的开源看板应用，官方提供了 Snap 安装方式，用户通过sudo snap install wekan即可在 Ubuntu/Debian 等 Linux 发行版上一键部署。Snap 包在系统中的落地形态包括：

/usr/bin/snap：snap 客户端命令行工具本身；
/var/snap：所有 snap 包的数据、配置与运行状态存放目录。

从 snapcraft.yaml 的environment声明可以看到，Wekan 的运行时数据路径被固定为：

SNAP_DATA=/var/snap/wekan/<revision>：当前版本的可写数据（数据库等）；
SNAP_COMMON=/var/snap/wekan/common：跨版本共享的配置（如 Caddyfile、MongoDB 数据）。

这些信息在 Troubleshooting 中也有印证：数据库和其他设置位于/var/snap/wekan/common/，而/snap/wekan/current是 squashfs 镜像的只读挂载。

问题的关键在于：/usr/bin/snap和/var/snap默认权限对普通用户是开放的。如果服务器上有多个登录用户、其中一些人没有 root 权限，他们依然可能调用snap命令读取系统 snap 状态、查看 Wekan 的运行信息，甚至干扰更新流程。对于多用户共享服务器这一典型场景，将 snap 客户端与数据目录都收窄为“仅 root 可访问”，是最简单也最有效的一道防线。

第一步：固定 Snap 自动更新窗口

Snap 默认会在包发布后自动刷新（refresh），这可能导致在任意时刻发生版本升级。为了让权限收紧策略可预期，第一步是把更新限制在一个固定的时间窗口内。

官方文档 Automatic-update-schedule 给出了多种refresh.schedule写法，本指南推荐使用的示例为：

sudo snap set core refresh.schedule=02:00-03:00

这表示核心（core）组件的自动刷新只会在每天凌晨 02:00 到 03:00 之间发生。类似的调度写法还包括：

调度意图	命令
每天凌晨 02:00–04:00 自动更新	`snap set core refresh.schedule=02:00-04:00`
每周日 02:00–04:00 更新一次	`snap set core refresh.schedule=sun,02:00-04:00`
每月最后一个周日 02:00–04:00 更新	`snap set core refresh.schedule=sun5,02:00-04:00`

说明：refresh.schedule是 snapd 提供的历史调度配置项。更新版本的 snapd 引入了更细粒度的refresh.timer（支持timer与hold语义），Install.md 中提到 Wekan Snap 的新安装流程已推荐改用refresh.timer。如果需要在某一天之前彻底冻结更新，可结合refresh.hold使用。本文方案基于文档中的refresh.schedule写法，二者在功能目标上一致：把自动更新收拢到明确的、与后续 cron 收紧动作衔接的时间窗内。

如果希望完全关闭自动更新，Automatic-update-schedule 还提供了一种“软禁用”手段：在/etc/hosts中把 snap 更新服务的域名指向本机：

127.0.0.1 api.snapcraft.io

这样 snapd 无法连接更新源，自然不会触发自动刷新。需要手动升级时再执行sudo snap refresh（参考 Update-all-snap-packages）。

第二步：用 cron 在每次更新后恢复 root 权限限制

时间窗只决定了“何时更新”，并不会自动维护权限。因为 snap 在刷新时可能重置或覆盖客户端与数据目录的权限位，所以需要一套机制保证“每次更新之后，权限立刻回到仅 root 的状态”。文档给出的做法是使用 root 的 crontab 定时任务。

2.1 进入 root 并编辑 cron

首先切换到 root，并把编辑器指定为 nano，然后打开 root 用户的 crontab：

sudo su export EDITOR=nano crontab -e

2.2 添加权限收紧任务

在 crontab 中追加以下两行：

10 3 * * * chmod og-rwx /usr/bin/snap 10 3 * * * chmod -R og-rwx /var/snap

逐项拆解这两条规则：

10 3 * * *：每天凌晨 03:10 执行（分时日月周的标准 cron 格式）。它刻意安排在刷新窗口 02:00–03:00结束之后 10 分钟，从而保证：更新先完成，权限随后立刻被收紧，中间的“开放窗口”最短。
chmod og-rwx /usr/bin/snap：去掉other（其他用户）和group（组）对该文件的读、写、执行权限，使snap命令仅对 root 可执行；
chmod -R og-rwx /var/snap：-R递归作用于整个/var/snap目录树，把其中所有数据、配置、套接字文件的组与其他用户权限全部移除。

/var/snap正是 snap 数据的存储位置，这与本文场景中的权限对象一一对应：命令本体在/usr/bin/snap，数据在/var/snap。收紧之后，普通用户既无法执行 snap 命令，也无法浏览 Wekan 在/var/snap/wekan/common/下的数据库与配置。

2.3 验证

完成编辑并保存后，可以执行以下命令验证 cron 配置已生效：

crontab -l

输出中应能看到刚添加的两条chmod规则。想手动立即收紧权限（不必等凌晨 03:10），可以直接执行一次：

chmod og-rwx /usr/bin/snap chmod -R og-rwx /var/snap

2.4 关于 cron 语法的说明

原文档提示可以使用在线 cron 语法校验工具来确认调度表达式的正确性（例如验证10 3 * * *表示“每天 03:10”）。对本文方案而言，两条规则必须使用相同的时间点，并且该时间点应严格晚于第一步设置的刷新窗口结束时刻——这是整套方案“先更新、后收紧”时序成立的关键。

原理补充：snap 更新的数据与权限模型

理解了命令，再看一下它为什么可靠。Wekan Snap 每次刷新都会拉取新的 squashfs 镜像并挂载到/snap/wekan/<revision>，而可写数据始终落在/var/snap/wekan/下（详见 snapcraft.yaml 的环境变量定义与 Troubleshooting 的目录说明）：

/snap/wekan/current：只读的 squashfs 镜像，普通用户本就无法修改；
/var/snap/wekan/current：当前版本的可写数据；
/var/snap/wekan/common/：跨版本共享的设置与数据库。

正因为版本目录会随刷新更替、/var/snap下会持续产生新目录与文件，单靠“安装时改一次权限”是不够的——新版刷新很可能带来默认权限的文件。cron 中chmod -R og-rwx /var/snap的递归语义恰好覆盖了这种持续变更：无论刷新后新增了哪些子目录，每天 03:10 都会被统一收拢权限。

从运维验证角度，收紧前后可以通过以下命令对比观察：

ls -l /usr/bin/snap ls -ld /var/snap

收紧前通常形如-rwxr-xr-x与drwxr-xr-x；执行chmod og-rwx之后应变为-rwx------与drwx------。此外，Wekan 的运行状态可通过sudo systemctl status snap.wekan.wekan检查（见 Install.md），确认权限收紧没有影响服务本身——因为 snapd 守护进程以 root 身份运行，收紧普通用户权限并不会妨碍 Wekan 的正常工作。

运维提醒与边界

这套方案的定位是“多用户共享主机上的最小权限收口”，需要注意以下几点：

它不替代访问控制：chmod只限制本地文件系统层面的访问。文档在 Install.md 中明确指出，若对安全要求极高，应把服务放在防火墙之后、不向互联网开放端口。
权限收紧是周期性的，而非事件驱动的：cron 方案在“刷新完成后的下一个 03:10”才会生效。若希望更新后立刻收紧，可在执行sudo snap refresh后手动补跑一次上面的两条chmod命令。
多用户权限控制是 snap 生态的长期课题：原文档指出，snap 官方社区正在讨论为 snap 引入更细粒度的“多用户与多组”权限模型（即未来可能提供面向不同用户/用户组的权限管理特性），届时将能替代这种基于chmod的全量收窄方式。在相关特性落地之前，本文的 cron + chmod 组合仍是文档推荐的、可直接落地的方案。

小结

针对「服务器存在无 root 权限的普通用户」这一场景，Wekan Snap 实例的 root-only 权限限制共分两步：

固定更新窗口：sudo snap set core refresh.schedule=02:00-03:00，让自动更新只发生在明确的时间段内；
更新后自动收紧：在 root crontab 中写入10 3 * * * chmod og-rwx /usr/bin/snap与10 3 * * * chmod -R og-rwx /var/snap，确保每次刷新完成后，snap 命令与/var/snap数据目录的组权限、其他用户权限都被立即移除，仅保留 root 访问权。

该方案直接对应 Limit-snap-to-root-user-only 的官方文档指引，并与仓库内的 Install.md、Automatic-update-schedule、Troubleshooting 及 snapcraft.yaml 相互印证。对多用户服务器上的 Wekan 部署者而言，这两条 cron 规则加上一个固定的刷新时间窗，就能以极低的成本显著收敛本地攻击面。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析