gstack 部署 Supabase RLS 收紧迁移后如何用 verify-rls.sh 验证读与更新已被拦截【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstackgstack 的遥测数据存储在 Supabase 上supabase/migrations/002_tighten_rls.sql这条迁移把 anon key 对所有遥测表的 SELECT 策略和 installations 表的 UPDATE 策略全部移除只保留 INSERT 策略供 v0.11.16 之前的旧客户端继续直写 PostgREST。迁移部署到 Supabase 项目后需要用supabase/verify-rls.sh跑一遍冒烟测试确认三件事读请求确实被 RLS 拦截、对 installations 的更新确实被拦截、INSERT 仍然放行否则旧客户端会坏掉。这个脚本就是 0.11.16.0 版本随迁移一起引入的配套验证工具。002 迁移做了什么脚本在验证什么002_tighten_rls.sql 的关键动作DROP POLICY移除telemetry_events、installations、update_checks三张表上的anon_select策略DROP POLICY移除 installations 上不受限的anon_update_last_seen策略原策略允许更新全部列REVOKE SELECT显式收回crash_clusters、skill_sequences两个视图的 anon 读权限注释里写作 belt-and-suspenders三张表的anon_insert_only策略保留注释明确说明这是为了 v0.11.16 之前的旧客户端待 edge-function 同步普及后才会在后续迁移中移除。脚本头部注释verify-rls.sh声明的验证目标与之一一对应SELECT denied on all tables and views、UPDATE denied on installations、INSERT still allowed。运行前提需要bash和curl脚本内部用curl发请求mktemp建临时响应文件需要能访问 config.sh 里配置的 Supabase 项目地址。该文件自动提供两个变量GSTACK_SUPABASE_URL项目 URL和GSTACK_SUPABASE_ANON_KEY公开 key注释说明 RLS 已拒绝 anon key 的一切数据访问因此安全可提交仓库脚本必须针对已经部署了 002 迁移的 Supabase 项目运行否则验证结果没有意义。一个必须在运行前明确的副作用第三组 INSERT 检查会向该项目的telemetry_events、update_checks、installations表真实写入测试行如gstack_version: verify_rls_test、installation_id: verify_rls_test。这是脚本设计如此——它要验证的就是INSERT 仍然放行。如果你不想在生产数据里留下这些测试行应在测试环境项目上运行或运行后自行清理。执行验证在 gstack 仓库根目录运行脚本verify-rls.sh 头部注释给出的方式bash supabase/verify-rls.shCHANGELOG 中另外记录过cd supabase ./verify-rls.sh的等价写法两种方式都是文档中出现过的真实命令。脚本会依次执行 9 项检查全部走${GSTACK_SUPABASE_URL}/rest/v1/路径携带apikey和Authorization: Bearer头值就是 anon key检查项方法预期SELECTtelemetry_events/installations/update_checks/crash_clusters/skill_sequences各 1 条GETdenyUPDATEinstallationsinstallation_ideq.test_verify_rlsbody{gstack_version:hacked}PATCHdenyINSERTtelemetry_events/update_checks/installationsPOSTallow如何判断结果每个检查打印一行PASS、FAIL或WARN结束后输出汇总Results: 9 passed, 0 failed (of 9 checks) VERDICT: PASS — reads/updates blocked, inserts allowed以上为脚本输出格式PASS/FAIL 行是脚本按判断逻辑拼接生成的具体每条的 HTTP 码取决于服务端响应Results与VERDICT行的文案来自 verify-rls.sh。退出码全部通过为 0有任何 FAIL 或 WARN 时打印VERDICT: FAIL并以 1 退出。deny 类检查的判定规则verify-rls.sh值得留意因为 HTTP 码相同但含义不同返回401/403被拒绝PASSGET 返回200且响应体是[]或空说明 RLS 在行级过滤了数据PASS输出注明 RLS filteringGET 返回200且有数据说明数据泄漏FAILPATCH 返回204没有行被修改——无论原因是 RLS 拦截还是行不存在攻击者都无法改数据计为 PASS连接失败HTTP 码记为000或其他未预期状态码记 WARN 并计入 failed最终VERDICT: FAIL。allow 类检查中200/201/204以及409主键冲突说明 INSERT 策略生效、行已存在都计 PASS若 INSERT 被拒401/403则 FAIL意味着迁移误删了旧客户端依赖的策略。两个会影响判读的版本细节003 迁移会改变 UPDATE 检查的语义。003_installations_upsert_policy.sql 在 002 之后重新给 installations 加了一条受限的 UPDATE 策略anon 通过列级GRANT UPDATE (last_seen, gstack_version, os)只能更新这三列first_seen和installation_id不可改。如果你的项目已经部署到 003脚本里那条gstack_version的 PATCH 检查即使服务端允许该列更新也会因为test_verify_rls这行不存在而返回 204脚本按no rows affected计为 PASS。也就是说这条检查在 002 之后的完整迁移链上验证的是匿名调用者无法造成数据变更而不是字面上的UPDATE 语句被策略拒绝。旧版脚本的边界 case 已修复。CHANGELOG0.11.16.1记录了verify-rls.sh曾存在的误判现在 INSERT 成功、409冲突、204空更新都被正确处理为通过。如果你手上的脚本版本早于该修复遇到409/204时的判定结果可能和本文描述不一致建议先确认脚本内容。结论与限制成功条件唯一9 项检查全部 PASSVERDICT: PASS退出码 0即读/更新被拦截、INSERT 放行与 002 迁移的设计目标一致。任何FAIL或WARN含连接失败都意味着验证未通过要么迁移未部署到位要么 URL/anon key 配置config.sh与目标项目不符要么网络不通。脚本对mktemp失败会直接中止verify-rls: mktemp failed, aborting不使用可预测的 PID 路径回退——这是共享机器上防止响应文件被预建/符号链接攻击的行为遇到中止时应检查TMPDIR//tmp的可写性而不是绕开它。该脚本只覆盖 REST 层PostgREST RLS的 anon key 行为服务端的读写走 edge function 与service_role_key不在本脚本的验证范围内。【免费下载链接】gstackUse Garry Tans exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考