Repository navigation
[BUG] Invalid SQL catalog or schema silently executes destructive statements in the previous namespace #55
Description
Description
An explicitly supplied invalid SQL namespace does not stop execution. MiniLake catches a failed USE, then executes the user's statement in the connection's previous namespace. A request targeting a nonexistent catalog/schema can successfully delete rows from an unrelated table in the default database.
Verified against MiniLake 1.9.0 source at local commit e24f46a7753ff0be30df3d83978c370c817f89cd (based on upstream fe8837dcfac9df621dfabc440abc07ebb4cdbcbb; the affected code is unchanged). Reproduced using a real disposable HTTP server and fresh data, with Python 3.14.3, DuckDB 1.5.6, FastAPI 0.162.0 and, for MCP, mcp 1.30.0. No mocks or user data were used.
Affected Components
- services/sql_statements.py:675 —
_apply_default_namespace - services/sql_statements.py:739 —
_execute_sql_real_typed - Statement Execution REST API; MCP
run_sqlalso forwards an explicit catalog/schema into this path.
Steps to Reproduce
Use a disposable server with a fresh absolute data directory. All requests below use its base URL.
- POST
/api/2.0/sql/warehouseswith{"name":"namespace-repro"}; retain the returned ID as W. - POST
/api/2.0/sql/statementswith:{"warehouse_id":"W","statement":"CREATE TABLE namespace_guard AS SELECT 10 AS id UNION ALL SELECT 20"} - POST the same endpoint with:
{"warehouse_id":"W","statement":"DELETE FROM namespace_guard","catalog":"missing_catalog","schema":"missing_schema"} - Execute
SELECT * FROM unity_catalog.main.namespace_guardusing W and no namespace override.
Substitute the actual warehouse ID for W. A second verified variant uses an existing catalog with a nonexistent schema and produces the same fallback.
Expected Behavior
Reject the invalid explicit namespace before executing the statement. Both original rows remain intact.
Actual Behavior
Step 3 returns HTTP 200 with status.state=SUCCEEDED and affected-row count 2. Step 4 returns []: the rows in unity_catalog.main.namespace_guard were deleted.
Root Cause Analysis
_apply_default_namespace catches the DuckDB exception from USE, logs it and returns None. Its caller then unconditionally calls conn.execute(sql). The connection still has its prior default namespace, so an unqualified table resolves there and the statement can succeed.
Impact
A catalog/schema typo, deleted schema, or stale UI namespace can cause successful writes, updates, or deletes against the wrong data. Local fixtures and CI datasets can be irreversibly modified while the API reports success. This is a correctness/data-integrity finding within MiniLake's documented local usage.
Suggested Fix
Propagate namespace-selection failure as a structured statement error and do not execute any SQL after it. Validate/quote namespace identifiers consistently and keep connection restoration in the protected execution path.
Test Coverage Gaps
Namespace tests cover valid namespaces and missing tables. Add invalid-catalog and invalid-schema cases with a same-named table in the previous namespace; assert failed status and byte-for-byte/row-for-row unchanged data. Include DELETE, UPDATE, INSERT and MCP forwarding.
Severity
High
Confidence
High — real HTTP reproduction with observed row deletion and traced execution path.
Recommended Labels
bug, high-priority
Existing Issue Matches
No reasonable duplicate found. Reviewed all open issues, the closed-issue search (no results), and all open PRs, then searched the affected functions/components and symptoms. Open PR #54 fixes duplicate Arrow columns only; #29 updates virtualenv. Neither addresses this defect. The documented local/single-user limitations were checked.
Issue #50 concerns jobs discarding a saved query's valid context. This defect occurs when Statement Execution is explicitly given an invalid context and then silently falls back.
Activity