Files
dsh_shenxian/dsh-server-docs/04-调整方案/02-安全加固-权限边界与DB.md
T
admin 5ad755116e chore(docs): 文档库并入代码仓(R4 选 a)+ 索引/台账跟进
1) dsh-server-docs/ 从工作区(原 E:\...\aliyun-dsh-server\dsh-server-docs)**整体并入本仓**,
   保留目录名 ⇒ 仓库内 dsh-server-docs/... 的相对引用天然继续有效;旧目录(含其 .git)已归档到
   工作区 _中间产物_待清理/,未随本提交带入。
2) .gitattributes:新增 `dsh-server-docs/** -text` —— 原文档库是 `* -text` + autocrlf=false,
   必须保持纯 LF,否则会被本仓的 CRLF 规则翻掉。
3) 活引用里的绝对路径已全部改到新位置(docs 的 INDEX / README / scripts / skills + 用户级 skills
   + ~/.workbuddy/settings.json 的 hooks);历史档案(04-调整方案/、archive/)按「只增不改」未动。
   ⚠️ hooks 路径改动需「完全重启会话」才生效(配置是会话启动快照)。
4) 交接单/T08:新增 §16「生产整体切换执行记录」(形态 / 落地动作 / **4 个只有真上线才暴露的真 bug** /
   验收证据 / 回滚命令 / 残留项);台账 T08 行 → 已完成并归档;03-路线图 §二 登记 T08 收尾项。
5) 统一称谓:**「本机」只指跑 WorkBuddy 的开发机**,47 / 106 一律写「远程服务器」。
2026-09-15 18:47:13 +08:00

3.1 KiB
Raw Blame History

十七、权限边界实测 + DB 权限安全加固(2026-09-08)

问题:admin 登录后能否访问服务器所有目录?AI 对话窗口新建工作空间时能否输入系统根目录?

两层防护模型(答案分两层):

层 机制 结论
Web 桌面层 fs-guard resolveWithinRoot():所有文件浏览/上传/新建工作空间的路径解析被锁在用户自身 home/ws 内,拒绝 ../、绝对路径、符号链接逃逸 输入 /、/root 等系统路径会被拉回/拒绝;admin 与普通用户同样受限,不存在"admin 浏览全服务器"入口
AI 进程层 每用户 DSH 实例以降权 uid(setpriv)运行,该进程可执行 shell/agent 工具,不受 fs-guard 约束,能读该 uid 有权限的一切文件 admin 的实例同样是降权 uid,非 root。实测 uid 114801 边界:/root、/etc/shadow、/opt/dsh/.env、secret.key、dsh db 全部 Permission denied ✅;/etc/passwd、/tmp 世界可读可写 ✅

结论:即便 admin 也无法从 AI 对话触达 root-only 敏感文件;真正的服务器管理走 SSH/宝塔 root 通道,与 AI 会话隔离。这是 account 隔离模式的核心价值,无需额外改造。

⚠️ 实测发现并修复的漏洞:DB 权限 644 → 600

项 详情
漏洞 /var/lib/dshs/dshs.db 权限 644 root——任意降权账号可 cat 拖库
风险 库内含全部用户 pass_hash(scrypt)+ api_key_ref(AES-GCM 密文)+ uid/sid → 离线爆破口令 + 窃取 key 密文
修复 chmod 600 /var/lib/dshs/dshs.db* /var/lib/dshs/dshs.db*
验证 降权账号读 db → Permission denied ✅;服务 600 下正常(portal 401 为未认证正常响应)✅

目录级权限收紧(用户反馈"其他用户也能看就不行",2026-09-08 20:30):

普通用户实例同样是降权 uid,盘点发现除主 db 外还有更大泄露面:/opt/dshs 整棵树 755、/opt/dsh/docs/ 内主库备份(含全部 pass_hash+key 密文)、/opt/dsh/backups/ 备份包、/opt/dsh/users/main 旧数据残留均 644/755 可读 → AI 会话可拖取。收紧如下:

路径 改前 改后 说明
/opt/dsh 755 700 覆盖 docs(含 db 备份)、backups、users/main 残留
/opt/dshs 755 700 root 服务运行不受影响(systemd 无 User= 默认 root)
/var/lib/dshs 755 711 保留 o+x:降权进程需穿过根路径进入自己 home,去读防列表泄露
.../users 755 711 同上;用户目录本身 700 保持隔离

验证(uid 114801 实测):读 /opt/dsh/docs/*.md → denied ✅;列 /opt/dshs、数据根 → denied ✅;仍可进入自己 ws/mcnworkspace ✅;systemd active、portal 200、admin 实例 /plugins/events 正常 ✅。

⚠️ 经验固化(Linux 目录权限设计):数据根这类"root 服务 + 降权子进程都要访问"的目录,权限用 711/700(去 r 留 x),不能收 700——降权进程会因无法穿过根路径而崩溃(EACCES)。子目录各自 700 才是真正的隔离边界。