Sealmarkdocs methodology 0.3-draft
methodology 0.3-draft

sqlite-file-write

SQLite: no writing of other files

shipped

The sections below are generated from the CLI (methodology 0.3-draft, CLI 0.3.0); the same text is printed by sealmark explain sqlite-file-write.

pack
sqlite
weight
critical
scope
server (tested through its SQL tool against a seeded SQLite file; the engine itself is not what is graded; SQLite only in this release, DuckDB is planned); the database file the server was given is the only file it should write
decided by
fs-observer
since
0.2-draft (methodology 0.3-draft)
config keys
checks.sqlite-file-write.corpus.addchecks.sqlite-file-write.corpus.removechecks.sqlite-file-write.enabledchecks.sqlite-file-write.severity

Probes

  • vacuum-into VACUUM INTO '{canary}/vac-<t>.db'
  • attach-new ATTACH '{canary}/att-<t>.db' AS a → CREATE TABLE a.t (x)
  • attach-new-one-call ATTACH '{canary}/att1-<t>.db' AS a; CREATE TABLE a.t (x) (one call)
  • ddl-prefixed-vacuum CREATE TABLE sm_p_<t> (x); VACUUM INTO '{canary}/vac-<t>.db' (a DDL-only tool, controlled through CREATE TABLE sm_ctl_<t> (x))
  • ddl-prefixed-attach-new CREATE TABLE sm_p_<t> (x); ATTACH '{canary}/att-<t>.db' AS a; CREATE TABLE a.t (x) (a DDL-only tool)
  • copy-to COPY (SELECT 1) TO '{canary}/c-<t>.csv' (DuckDB; planned, not run in this release)
  • export-database EXPORT DATABASE '{canary}/exp-<t>' (DuckDB; planned, not run in this release)

Settings and thresholds

Every check also takes checks.sqlite-file-write.enabled and checks.sqlite-file-write.severity; they are described once in the configuration reference.

This check has no numeric threshold.

KeyDefaultStandardMeaning
checks.sqlite-file-write.corpus.add[]lockedExtra probes for sqlite-file-write, validated against the pack's corpus schema. Appends across layers. Any addition makes the run CUSTOM.
checks.sqlite-file-write.corpus.remove[]lockedProbe ids or exact strings to drop from the sqlite-file-write corpus. Appends across layers. Any removal makes the run CUSTOM.

How the verdict is established

  • Scoring. critical and scored: pass = 1 point, part = 0.5, fail = 0. A fail caps the pack's grade at D, whatever the other checks scored.

What to fix

Block VACUUM INTO, ATTACH of new files and file-writing functions with an authorizer callback, so the only file the server can change is the database it was given; a declared read-only mode must cover every form that writes a file, not only INSERT, UPDATE and DELETE. A DDL-only tool is judged through CREATE TABLE controls, and a SQL tool that answers none of the control forms makes the check part.

False positives

A new or changed file in the canary directory is a write outside the database the server was given, so no false positive is known. -wal, -shm and -journal files next to the fixture are noted, never counted. A declared writer tool is probed like any other, because VACUUM INTO and ATTACH need no read control and the file observer decides; a tool whose SELECT and INSERT controls both fail is controlled through CREATE TABLE sm_ctl_<t> (x) (verified in the fixture) and probed behind a CREATE TABLE prefix. A SQL tool that failed every control (neither a control read nor a control write nor a control CREATE TABLE worked) is listed under not covered and the check is part at best, never a pass. A write through any one tool fails the check, however many other tools are clean.

False negatives

VACUUM INTO writes under a read-only connection (observed). Attaching a new file under a read-only connection failed in the engine used here, so that probe is an attempt, not an expectation.