Can I get a callback / do I know when SQLite has created write-ahead log files? I want to chmod them

Question

I have an elevated process and I want to make sure the SQLite files that it creates are readable by other processes. For some reason umask doesn't seem to do what I want (set permissions of sqlite file created by process).

I'm using write-ahead logging, so -wal and -shm files are created in addition to the database file. I want all 3 to be chmodded correctly.

I wonder if it's possible to get in after the SQLite file is created and chmod it.

Possible approaches:

1. touch all 3 files before SQLite tries to create them, then chmod and hope the mask stays the same
2. Intercept when the files are created and chmod them.
3. Work out how to get umask to work for the process.
4. Mystery option four.

What's the best way to go?

Questions for approaches:

1. Will SQLite be OK with this?
2. Do we know when all 3 files are created? Is there some kind of callback I can give a function pointer to? Do we know if the same wal and shm files are around forever? Or are they deleted and re-created?

Answer 1

You can touch the database file before opening it. (When you use the sqlite3 command-line tool to open a new file, but do nothing but begin; and commit;, SQLite itself will create a zero-sized file.)

If you want to intercept file operations, you can register your own VFS.

The -wal and -shm files are created dynamically, but SQLite will give them the same permission bits as the main database file. The comments for robust_open() in os_unix.c say:

If the file creation mode "m" is 0 then set it to the default for SQLite. The default is SQLITE_DEFAULT_FILE_PERMISSIONS (normally 0644) as modified by the system umask. If m is not 0, then make the file creation mode be exactly m ignoring the umask.

The m parameter will be non-zero only when creating -wal, -journal, and -shm files. We want those files to have exactly the same permissions as their original database, unadulterated by the umask. In that way, if a database file is -rw-rw-rw or -rw-rw-r-, and a transaction crashes and leaves behind hot journals, then any process that is able to write to the database will also be able to recover the hot journals.