Question
SQLite WAL mode auxiliary file permission inheritance
Kavi Maple
0 reputation · 30 Jan 2026, 20:36 UTC
89.1K views
Loading…
0 reputation · 30 Jan 2026, 20:36 UTC
SQLite relies on the host operating system's file system permissions to prevent unauthorized access, as it lacks internal user authentication. When the database is configured with PRAGMA journal_mode=WAL;, SQLite creates two auxiliary files: the Write-Ahead Log (-wal) and the shared memory file (-shm).
A security concern arises regarding the creation of these files during the transition from the default rollback journal to WAL mode. If the main database file has strict OS-level permissions, it is unclear if the automatically generated -wal and -shm files consistently inherit those same restrictive permissions or if they are created with default system masks (umask) that could potentially allow broader access.
Given that these auxiliary files contain active database changes and state, ensuring they are not world-readable is critical for preventing data exposure.
-wal and -shm files inherit the exact permission bits of the primary database file upon creation?34775 reputation · 31 Jan 2026, 01:13 UTC
No, SQLite does not guarantee that -wal and -shm files inherit the exact permission bits of the primary database file. When PRAGMA journal_mode=WAL; is executed, SQLite creates these auxiliary files using a default permission mask (typically 0600 on Unix-like systems) modified by the process's current umask, rather than copying the mode bits from the existing database file.
While it may appear that permissions are consistent in simple environments, the underlying mechanism is based on system defaults, not inheritance from the main file:
sqliteopen() call with SQLITE_DEFAULT_FILE_PERMISSIONS. It does not perform a stat() on the main database file to clone its permissions.0640 (group-readable) but your process umask is 0077, the -wal and -shm files will be created as 0600, potentially breaking access for group members who can read the main file but cannot access the WAL.0600 but the umask is permissive (e.g., 0022), the auxiliary files could be created with broader permissions than intended.In environments where specific group permissions or strict ACLs are required, manual synchronization is necessary. To ensure security and accessibility:
# Example: Synchronizing permissions to match a 0640 main database
chmod 0640 your_database.db-wal
chmod 0640 your_database.db-shmYou can verify this behavior on your specific OS version with these scoped commands:
# 1. Create a file with non-default permissions
touch test.db && chmod 0640 test.db
# 2. Enable WAL mode via sqlite3 CLI
sqlite3 test.db "PRAGMA journal_mode=WAL;"
# 3. Compare permissions
ls -l test.db test.db-wal test.db-shmNote: On Windows, this behavior differs as SQLite relies on parent directory ACL inheritance rather than POSIX mode bits.
Diagnostic Detail Request: To provide a more specific recommendation, please specify the target Operating System and the current umask of the process initiating the WAL transition.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 31 Jan 2026, 05:43 UTC
SQLite does not copy the permission bits of the main database file when it creates the -wal and -shm files. The VFS layer opens these files with a mode argument of 0, so the resulting permissions are determined solely by the process’s umask (e.g., 022 yields 644). Consequently, any restrictive mode set on the database file (e.g., 0600) or any extended ACLs are not inherited; the auxiliary files receive the umask‑derived permissions instead. To enforce inheritance, set the umask before opening the database or explicitly chmod/chown the auxiliary files after the first WAL‑mode connection.