Skip to content

run_sql: durable memory-amplification защита (allowlist на функции + cell-size cap преди capRows) #227

Description

@nedda76

Контекст

Guard-ът на run_sql пази срещу memory-amplification (цял table scan, колабиран в една огромна клетка, която се материализира преди capRows) чрез денилист на опасни скаларни/агрегатни функции в apps/web/app/lib/assistant/sql-guard.ts. По време на ревюто на #223 денилистът беше разширяван на няколко пъти (group_concatjson_group_array/json_group_objectstring_agg).

Денилистът по природа е catch-up игра: всеки нов алиас/функция от нова версия на SQLite трябва да се добавя ръчно (string_agg е синонимът на group_concat от SQLite 3.44; D1 върви на съвременна SQLite). Прихванахме го при ревю, но следващият алиас може да се промъкне.

Предложение (2 допълващи се посоки)

  1. Позитивен allowlist на функциите (durable fix). Вместо денилист — allowlist на позволените скаларни/агрегатни/date функции за read-only аналитика; всичко извън него fail-closed. Така нов алиас пада по подразбиране, без да го гоним поотделно. Бел.: на feat/ai-assistant (feat(ai-assistant): conversational analytic layer (BgGPT) #79) слой L2 (sql-ast-guard) вече има такъв позитивен allowlist — струва си да се пренесе към guard-а на main, или L1 да делегира на него.

  2. Твърд таван върху размера на клетката преди capRows. capRows пази първия ред цял; един голям низ в една клетка минава. Таван върху байтовете на отделна клетка (преди/по време на четенето) затваря и остатъка, който денилистът не може — напр. краен, но огромен || chain (SELECT a||a||…||a), който не ползва нито една блокирана функция.

Референции

Metadata

Metadata

Assignees

Labels

priority: mediumСреден приоритетsecurityСигурност и уязвимости

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions