Surfaced while verifying an external security review of PR #122 (which correctly noted the guard as a pre-existing, unchanged limitation).
src/lib/db/providers/sql/sqlite.ts getDatabasePath() comments 'reject path traversal attempts', but the condition 'resolved !== path.normalize(resolved)' can never be true (path.resolve output is already normalized), so the check only rejects NUL bytes. Within the product trust model this is not a vulnerability - the sqlite path is provided by an authenticated admin and pointing at arbitrary server-side files is the feature - but the comment promises protection the code does not provide.
Options:
- Honest minimum: fix the comment (NUL rejection only) and document in docs/providers/sqlite.md that sqlite paths are admin-trusted server paths.
- Optional hardening: a LIBREDB_SQLITE_BASE_DIR allowlist env restricting resolvable paths for deployments that want to sandbox file access (useful with the new native packages where the service user is confined anyway).
Either way, sync docs/providers/sqlite.md and the integration tests per the provider tri-sync invariant.
Surfaced while verifying an external security review of PR #122 (which correctly noted the guard as a pre-existing, unchanged limitation).
src/lib/db/providers/sql/sqlite.ts getDatabasePath() comments 'reject path traversal attempts', but the condition 'resolved !== path.normalize(resolved)' can never be true (path.resolve output is already normalized), so the check only rejects NUL bytes. Within the product trust model this is not a vulnerability - the sqlite path is provided by an authenticated admin and pointing at arbitrary server-side files is the feature - but the comment promises protection the code does not provide.
Options:
Either way, sync docs/providers/sqlite.md and the integration tests per the provider tri-sync invariant.