[acmeguy]

Why

#102 refused the duckdb, sqlite, jdbc, databricks-jdbc and cubestore types for tenant datasources. Database support must never disappear. This restores every type Cube knows and removes only the settings that reach the cube pod or other tenants. Join aliases (new in Cube 1.8) work under row rules instead of being refused.

An adversarial review of the first version found bypasses. All of them are fixed in the second commit, and the reviewers' exploits were rerun against the fixed image and are closed. A second review of the new design is running.

What each type keeps, and what it loses

Type	Works	Taken away
DuckDB	:memory:, MotherDuck, files in the datasource's own directory CUBEJS_LOCAL_DB_ROOT/<datasource id>/ (read and write, with spill), remote prefixes listed by the operator in CUBEJS_DB_DUCKDB_ALLOWED_PATHS	Every other path, at creation (no extension auto-install or auto-load) and before any tenant SQL (allowed directories, external access off, config locked; the driver refuses to start if /proc/self/environ is still readable); the S3 credential chain (the pod's own AWS credentials)
SQLite	Files in the datasource's own directory, :memory:. It loads again, because sqlite3 is built from source	Other paths, and ATTACH. It is read-only, so rollups are built into Cube Store
Generic JDBC	Network JDBC URLs; driver jars from CUBEJS_JDBC_DRIVERS_DIR, one jar per entry	The Derby/HSQLDB jars in node_modules; in-process URLs (checked against the exact network forms)
Databricks	jdbc:databricks:// / jdbc:spark:// URLs	Driver logging settings in the URL (they write files and trace other tenants' connections)
CubeStore	An external store reached over ws/wss (http/https are rewritten to them); plain connections are pinned to the address that was checked	Our own CubeStore, by name or address, including IPv4-mapped forms; private networks, NAT64 and 6to4 addresses, unless CUBEJS_CUBESTORE_DATASOURCE_ALLOW_PRIVATE=true (on-prem, which then needs a NetworkPolicy)

Row rules

• Member paths resolve with Cube's own resolver on the model compiled for the request (index.js). Aliases, and plain joins after an alias, get the joined cube's rules: orders.customer.events.event gets orders.customer.events.partition.
• SQL API member expressions get rules for the cubes they read; while rules apply, an expression shape it can't read is refused.
• A blocked query with only time dimensions still gets its sentinel; with nothing to attach the sentinel to, the query is refused.

Verification

• Image yarn test: 743/743.
• Behaviour tests against the installed, patched drivers:
  • DuckDB writes and spills inside its own directory; environ reads, ATTACH … (TYPE sqlite), writes to /tmp or /app, LOAD, ../ traversal and unlocking are all refused.
  • SQLite is read-only and refuses ATTACH.
• End-to-end queryRewrite with the real resolver on a compiled model: alias-then-join, member expressions and the blocked sentinel.
• Reviewers' exploits rerun against the fixed image:
  • SQL API member expression: the other tenant's row is no longer returned;
  • alias then plain join: filtered;
  • CubeStore DNS rebinding over http://: pinned;
  • mapped IPv6 and ws+unix://: refused.
• Earlier on this PR, end to end: DuckDB and SQLite datasources on a local 1.8.16 server: /test ok, get-schema ok, a SQLite path outside its directory refused.

Round two (second adversarial review, all confirmed findings fixed, exploits rerun and closed)

• DuckDB extensions: operator extensions must be ones whose file and network access goes through DuckDB's own checks. The sqlite, postgres and mysql scanners don't, so with them configured the datasource refuses to start. Loaded extensions are checked before the lock, and nothing can load after it. The image ships httpfs, aws, motherduck and excel; instances can load them but never download.
• DuckDB secrets: operator S3 credentials become a redacted DuckDB secret, and the readable s3_* settings are reset. Persistent secrets are off, so tenant CREATE SECRET works.
• DuckDB logging: CALL enable_logging and enable_profiling are refused, since the lock doesn't cover them.
• MotherDuck: it opens again; a path without a token is refused instead of blocking on an interactive login.
• SQLite:
  • an unopenable file fails its queries instead of crashing the pod;
  • per-datasource directories are created;
  • in-source pre-aggregations get a clear "must be external" error;
  • the pragmas that change the temp and data directories are refused.
• Row rules: a PatchMeasure whose filters reach a ruled cube is ruled.
• CubeStore: the port must be numeric (it could carry a host through userinfo); host and port become a pinned URL.
• JDBC:
  • driver logging settings are refused for every JDBC-family type, in the URL or the properties;
  • generic JDBC and Databricks share one complete JVM class path, so either works whichever connects first.
• Tests: image yarn test 748/748.

Known pre-existing row-rule gaps (on main too, not changed here)

Rules are derived by re-reading model files, not from Cube's compiled model. As a result:

• views get no rules;
• JS models the parser can't read are skipped silently;
• extends children don't inherit the parent's table;
• member SQL that references joined cubes isn't ruled for those cubes;
• meta.source_table can steer table resolution;
• YAML merge keys are read differently from Cube.

The fix is to build the rule map from Cube's compiled model (follow-up).

🤖 Generated with Claude Code