mirror of
https://github.com/ThearchyHelios/AgentLab.git
synced 2026-11-15 01:01:59 +00:00
ThearchyHelios
8c0c3b8eeb
复核查出，上一轮放开「没碰遮罩列的快照照常附带」之后，有几种写法 SQL 里不写 phone、结果列名也对不上，结果里照样是 号码，快照原字节和查询事件的预览会随文件附带出去。这一轮逐条堵上： - 整行引用认全（复核的两个阻断项）：Postgres 的 FROM 里的表函数不写 LATERAL 也看得见前面的来源， `FROM members m, jsonb_each_text(to_jsonb(m))` 这类逐列画像的写法（逗号、CROSS JOIN、JOIN … ON TRUE、LEFT JOIN、 ROWS FROM、不带别名的 UNNEST、套在 FROM 的子查询里）以前按看不见算，整行引用认不出。现在 FROM、JOIN 里只有真的 子查询和 WITH 里的一段看不见同一层；括号括起来的一组连接（(members m CROSS JOIN f(m))）也摊开按同一层认。另外认 函数记法 m.to_jsonb、m.row_to_json（等于 to_jsonb(m)），自己建的函数认不出。 - 不点列名也读得出表里内容的写法（_INDIRECT_READS）：SQL、表名写在字符串里交给函数执行或整表导出（table_to_xml、 query_to_xml 一族、ts_stat、crosstab、DBMS_XMLGEN、XQuery 的 ora:view），统计信息里的采样值（pg_stats、 sqlite_stat4、column_statistics、Oracle 的直方图和 *_tab_columns），按页按文件读的原始数据（get_raw_page、 pg_read_file、LOAD_FILE、sqlite_dbpage、逻辑解码），别的会话的 SQL 原文（pg_stat_activity、general_log、V$SQL）， 系统 schema（pg_catalog、information_schema、performance_schema）。SQL 原文里出现就只给哈希；函数名要跟着左括号， 列名碰巧叫 crosstab、pg_status 的不受影响。 - 这次运行里查到过的遮罩值写进了别的查询的字面量（模型拿看到的号码去查别的表）：导出时收齐封存范围内每份快照里 取自遮罩列的格子（inquiry._Secrets 的按值认得出的写法），只看 SQL 的字面量，碰上就只给哈希、查询事件也只给哈希。 这次运行里没查到过的值（提问人写进问题的）认不出。 - MariaDB 会执行的注释 /*M! … */ 和 /*! … */ 一样按语法树认不准处理。 - 口径卡和快照按同一个结论判：快照因列名表、整行引用、不照原名展开的 *（UNION 一支里按位置对上列名的、装进一列 的）、吃进遮罩列的表函数、语法树认不准或不点列名也读得出内容而只给哈希时，卡上取自这份快照任一列的输入都按遮罩列 算，整张卡只给 id。以前卡这条路只认改了名字的遮罩列，快照只给哈希，卡上记着的号码却原样进了文件。最外层直接写的 * 照原名展开，按名字认就够，卡照常嵌入。 - check-bundle 的 masked-source 样本点数字之前先看有没有核对通过的数字，没有就记一项不通过、不去点：以前点空了要 等满 30 秒抛错，同一节后面的 nan、stray 样本都不跑了。换回改动前的 build.py 实测，现在只多记两项不通过，后面照常跑。 有意没改的一条：SQL 写到遮罩列、结果里却没有号码的（COUNT(DISTINCT phone)、phone IS NOT NULL）照旧只给哈希，比规格 的四条更严。FROM 里的表函数吃进遮罩列时（unnest(ARRAY[phone])）它交出的列取自哪一列认不出，只能看 SQL 写没写到； 补了这一例的测试，说明写在 _untouched 和测试里。 测试：新增整行引用（表函数、括号里的一组连接、函数记法）、不点列名的读法、字面量里的遮罩值、MariaDB 注释、口径卡 七种认不出来历的写法各自的用例，以及对照组（列名像函数名的、表函数只吃没设遮罩的列的、括号连接按名字取列的、最外层 * 的卡）。合并查询那一条判断补了只带认得的键的夹具，结果列名那一条补了按 SQL 认遮罩列的那一套什么都没认出来时的 用例，两条现在都能单独证明——上一轮提交说明里「每一条规则都做过去掉实现测试变红」对这两条不成立。这一轮 15 处改动 逐一去掉实现，相关测试都变红。