[PR #7061] [MERGED] Reject unrecognised DATABASE_URL instead of silent SQLite fallback #26085

New Issue

GiteaMirror · 2026-05-29T05:04:43-05:00

GiteaMirror commented

2026-05-29 05:04:43 -05:00

📋 Pull Request Information

Original PR: https://github.com/dani-garcia/vaultwarden/pull/7061
Author: @mfw78
Created: 4/7/2026
Status: ✅ Merged
Merged: 5/16/2026
Merged by: @BlackDex

Base: main ← Head: fix/sqlite-fallback-panic

📝 Commits (3)

32907bd Panic on unrecognised DATABASE_URL instead of silent SQLite fallback
e159210 Use err!() instead of panic!() for unrecognised DATABASE_URL
b68fb30 Use 'scheme' instead of 'prefix' in DATABASE_URL messages

📊 Changes

3 files changed (+44 additions, -20 deletions)

View changed files

📝 .env.template (+5 -4)
📝 src/config.rs (+12 -9)
📝 src/db/mod.rs (+27 -7)

📄 Description

Summary

When DATABASE_URL does not match mysql: or postgresql:, vaultwarden silently treats it as a SQLite file path. Any misconfiguration (typo, quoting issue, garbage value) quietly creates an empty SQLite database instead of erroring. In containerised environments this means data loss on restart, which has bitten me personally and others (#2835, #1910, #860).

The partial fix in #2873 catches some cases by checking the parent directory, but does not help when the path resolves within an existing directory.

The core issue is that SQLite selection is implicit. Database selection for a secrets manager should be explicit, not a fallback. An operator who misconfigures their database URL should get a clear error, not a silent downgrade to a different database engine entirely.

Changes

DbConnType::from_url now recognises an explicit sqlite: scheme. URLs without any recognised scheme are still accepted as bare-path SQLite for backwards compatibility, but only if the file already exists. Otherwise the process panics with a clear message.
Default DATABASE_URL changed to sqlite://{data_folder}/db.sqlite3 so new deployments use the explicit scheme.
backup_sqlite and validate_config updated to handle the sqlite:// prefix.
.env.template updated accordingly.

Test plan

Fresh deployment with default config creates database normally
Existing bare-path DATABASE_URL=data/db.sqlite3 (file exists) still works
Misconfigured URL (e.g. foobar) panics with a helpful message
SQLite backup works with sqlite:// prefix
MySQL and PostgreSQL URLs unaffected

Fixes #7062

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/dani-garcia/vaultwarden/pull/7061 **Author:** [@mfw78](https://github.com/mfw78) **Created:** 4/7/2026 **Status:** ✅ Merged **Merged:** 5/16/2026 **Merged by:** [@BlackDex](https://github.com/BlackDex) **Base:** `main` ← **Head:** `fix/sqlite-fallback-panic` --- ### 📝 Commits (3) - [`32907bd`](https://github.com/dani-garcia/vaultwarden/commit/32907bdaf543ac751570e0e652784c8daaefeb48) Panic on unrecognised DATABASE_URL instead of silent SQLite fallback - [`e159210`](https://github.com/dani-garcia/vaultwarden/commit/e159210323a017544c007c829f66ba5083daaac3) Use err!() instead of panic!() for unrecognised DATABASE_URL - [`b68fb30`](https://github.com/dani-garcia/vaultwarden/commit/b68fb30eca409dded980eef6ab4f56aa3154702e) Use 'scheme' instead of 'prefix' in DATABASE_URL messages ### 📊 Changes **3 files changed** (+44 additions, -20 deletions) <details> <summary>View changed files</summary> 📝 `.env.template` (+5 -4) 📝 `src/config.rs` (+12 -9) 📝 `src/db/mod.rs` (+27 -7) </details> ### 📄 Description ## Summary When `DATABASE_URL` does not match `mysql:` or `postgresql:`, vaultwarden silently treats it as a SQLite file path. Any misconfiguration (typo, quoting issue, garbage value) quietly creates an empty SQLite database instead of erroring. In containerised environments this means data loss on restart, which has bitten me personally and others (#2835, #1910, #860). The partial fix in #2873 catches some cases by checking the parent directory, but does not help when the path resolves within an existing directory. The core issue is that SQLite selection is implicit. Database selection for a secrets manager should be explicit, not a fallback. An operator who misconfigures their database URL should get a clear error, not a silent downgrade to a different database engine entirely. ## Changes - `DbConnType::from_url` now recognises an explicit `sqlite:` scheme. URLs without any recognised scheme are still accepted as bare-path SQLite for backwards compatibility, but only if the file already exists. Otherwise the process panics with a clear message. - Default `DATABASE_URL` changed to `sqlite://{data_folder}/db.sqlite3` so new deployments use the explicit scheme. - `backup_sqlite` and `validate_config` updated to handle the `sqlite://` prefix. - `.env.template` updated accordingly. ## Test plan - [ ] Fresh deployment with default config creates database normally - [ ] Existing bare-path `DATABASE_URL=data/db.sqlite3` (file exists) still works - [ ] Misconfigured URL (e.g. `foobar`) panics with a helpful message - [ ] SQLite backup works with `sqlite://` prefix - [ ] MySQL and PostgreSQL URLs unaffected Fixes #7062 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

GiteaMirror added the pull-request label 2026-05-29 05:04:43 -05:00

GiteaMirror closed this issue

2026-05-29 05:04:45 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/vaultwarden#26085