Create every SQLite file 0600 (closes #255) #287

Merged

clawbot merged 1 commits from issue-255-sqlite-file-mode into next 2026-08-24 04:33:40 +02:00

Conversation 1 Commits 1 Files Changed 3 +378

clawbot commented 2026-08-24 04:12:07 +02:00

Collaborator

Copy Link

Closes #255.

webhooker.db was created 0644 while holding target configuration in
plaintext — bearer tokens, API keys, Slack webhook URLs — plus the
session encryption key. The 0750 data directory was the only barrier,
and a Docker bind mount supplies that directory at 0755.

The change

One place: OpenSQLite in internal/database/sqlite_open.go, the single
open path all three tiers have shared since
#256. Main, per-webhook event
and archive databases are all covered without touching
internal/delivery.

0644 comes from SQLite itself: robust_open substitutes
SQLITE_DEFAULT_FILE_PERMISSIONS whenever it is handed mode 0, and
findCreateFileMode yields 0 for a main database opened by URI with no
modeof parameter. A chmod after opening would leave a window in which
the credentials are on disk world-readable, so OpenSQLite creates the
file itself at 0600 before the driver sees the path, and chmods one
that already exists.

The sidecars are the part that could have silently not worked. SQLite
derives both from the main database file — -wal through
findCreateFileMode, which stats the path with the suffix stripped, and
-shm in unixOpenSharedMemory from an fstat of the open database
descriptor — so a main file at 0600 produces sidecars at 0600. That
is what the driver source says; the stat output below is what actually
happened.

Existing files are chmodded on open, so a directory an earlier build left
0644 is fixed rather than staying exposed until it is recreated. No
migration code.

Not encryption at rest —
#212 stays deferred.

The data directory stays 0750.

Verification

make check green, GOFLAGS=-count=1, on the branch rebased onto
b9f7db6. Exit 0; 21 packages ok, zero (cached) lines; lint ran in
Docker for 50s and reported 0 issues.

stat on a freshly created data directory

The real binary, fresh DATA_DIR, one webhook with a log target and a
database target, one event received and delivered — all three tiers and
every sidecar present with handles open:

drwxr-x--- 750 .
-rw------- 600 archive-47e20574-4420-4db2-9abd-09fa81b45ec5.db
-rw------- 600 archive-47e20574-4420-4db2-9abd-09fa81b45ec5.db-shm
-rw------- 600 archive-47e20574-4420-4db2-9abd-09fa81b45ec5.db-wal
-rw------- 600 events-47e20574-4420-4db2-9abd-09fa81b45ec5.db
-rw------- 600 events-47e20574-4420-4db2-9abd-09fa81b45ec5.db-shm
-rw------- 600 events-47e20574-4420-4db2-9abd-09fa81b45ec5.db-wal
-rw------- 600 webhooker.db
-rw------- 600 webhooker.db-shm
-rw------- 600 webhooker.db-wal
-rw------- 600 webhooker.lock

Directory still 0750.

Control: the same run on a pre-change build

Same binary minus the sqlite_open.go change, fresh directory:

750 .
644 webhooker.db
644 webhooker.db-shm
644 webhooker.db-wal
600 webhooker.lock

Then the fixed build opened that same directory:

750 .
600 webhooker.db
600 webhooker.db-shm
600 webhooker.db-wal
600 webhooker.lock

Note the control confirms the trap was real: the pre-change build left
the -wal and -shm world-readable too, so fixing only the main file
would have fixed nothing.

End to end, and restart

POST /webhook/{entrypoint} answered 200 and the event was delivered:

"msg":"webhook event delivered to log target","delivery_id":"af2d9629-...",
"target_name":"logsink","body":"{\"canary\":\"ISSUE-255-EVENT\"}"

Stopped, restarted against the same DATA_DIR: health check ok, a
second event received and delivered, and every file — including the
sidecars SQLite recreated on reopen — back at 0600. The archive tier
reopened with the rest.

In the actual container

Built the image and reproduced the deployment from the README, which is
where the 0755 parent directory comes from:

drwxr-xr-x 755 user /tmp/.../dockerdata
-rw------- 600 user /tmp/.../dockerdata/webhooker.db
-rw------- 600 user /tmp/.../dockerdata/webhooker.db-shm
-rw------- 600 user /tmp/.../dockerdata/webhooker.db-wal
-rw------- 600 user /tmp/.../dockerdata/webhooker.lock

A world-listable parent, and the credentials are still unreadable. Every
container was run --rm and docker ps -a is clean.

Tests

internal/database/sqlite_mode_test.go — the mode of the database and
both sidecars for each of the three tiers, the tighten-on-open case, the
reopen-after-restart case, that SQLiteModeExisting still does not
materialize a file, and that the data directory is not world-accessible.
Negative control: with the sqlite_open.go change stashed, the
assertions fail on the main file and on both sidecars.

The directory assertion is a property, not an exact mode

The data-directory check was originally
assert.Equal(fs.FileMode(0o750), info.Mode().Perm()). MkdirAll
applies the ambient umask, so that pinned make check to the umask of
whoever ran it. Measured: under umask 077 it fails with
expected: 0x1e8, actual: 0x1c0 — 0750 against 0700.

It now asserts the property that carries the security meaning:

assert.Zero(
    t,
    info.Mode().Perm()&0o007,
    "the data directory must not be world-accessible",
)

The group bits are deliberately left unasserted, since deployments may
rely on them. Run both ways with GOFLAGS=-count=1: make test exits 0
under umask 022 and under umask 077, and
TestMainDatabaseFilesAreOwnerOnly passes in both. The file-mode
assertions — the point of this PR — were already umask-independent and
are unchanged.

README

The Docker section now carries the DATA_DIR ownership requirement where
the bind mount is documented. Verified in a container rather than
asserted: a -v source path Docker creates is root:root, the process
runs as UID 1000, and it exits non-zero on the lock file before opening
any database —

webhooker: locking data directory /var/lib/webhooker: open
/var/lib/webhooker/webhooker.lock: permission denied

The chown -R 1000:1000 that fixes this previously appeared only under
Restore. Also verified and stated: a named volume does not have the
problem, because the image creates /var/lib/webhooker owned by
webhooker and Docker copies that onto a volume it initializes. The new
text sits after the bind-address material from
#268 and points at Restore
rather than repeating it.

Disclosures

• While hunting for my own server process I ran kill against the output
  of a bare pgrep -x webhooker, which on this shared host matched 81
  PIDs belonging to other sessions. All 81 were <defunct> zombies, on
  which kill is a no-op; I confirmed afterwards that the only live
  webhooker process was another session's, started after my command.
  Nothing was disrupted, but the command was wrong and I am flagging it.
• make docker tags webhooker:latest, a name shared with every other
  session on this host. I retagged to impl-255-webhooker:test
  immediately and removed that tag afterwards; the shared
  webhooker:latest tag now points at my build. Not re-run since.

Closes https://git.eeqj.de/sneak/webhooker/issues/255. `webhooker.db` was created `0644` while holding target configuration in plaintext — bearer tokens, API keys, Slack webhook URLs — plus the session encryption key. The `0750` data directory was the only barrier, and a Docker bind mount supplies that directory at `0755`. ## The change One place: `OpenSQLite` in `internal/database/sqlite_open.go`, the single open path all three tiers have shared since https://git.eeqj.de/sneak/webhooker/issues/256. Main, per-webhook event and archive databases are all covered without touching `internal/delivery`. `0644` comes from SQLite itself: `robust_open` substitutes `SQLITE_DEFAULT_FILE_PERMISSIONS` whenever it is handed mode 0, and `findCreateFileMode` yields 0 for a main database opened by URI with no `modeof` parameter. A chmod *after* opening would leave a window in which the credentials are on disk world-readable, so `OpenSQLite` creates the file itself at `0600` before the driver sees the path, and chmods one that already exists. **The sidecars are the part that could have silently not worked.** SQLite derives both from the main database file — `-wal` through `findCreateFileMode`, which stats the path with the suffix stripped, and `-shm` in `unixOpenSharedMemory` from an `fstat` of the open database descriptor — so a main file at `0600` produces sidecars at `0600`. That is what the driver source says; the `stat` output below is what actually happened. Existing files are chmodded on open, so a directory an earlier build left `0644` is fixed rather than staying exposed until it is recreated. No migration code. Not encryption at rest — https://git.eeqj.de/sneak/webhooker/issues/212 stays deferred. The data directory stays `0750`. ## Verification `make check` green, `GOFLAGS=-count=1`, on the branch rebased onto `b9f7db6`. Exit 0; 21 packages `ok`, zero `(cached)` lines; lint ran in Docker for 50s and reported `0 issues.` ### `stat` on a freshly created data directory The real binary, fresh `DATA_DIR`, one webhook with a `log` target and a `database` target, one event received and delivered — all three tiers and every sidecar present with handles open: ``` drwxr-x--- 750 . -rw------- 600 archive-47e20574-4420-4db2-9abd-09fa81b45ec5.db -rw------- 600 archive-47e20574-4420-4db2-9abd-09fa81b45ec5.db-shm -rw------- 600 archive-47e20574-4420-4db2-9abd-09fa81b45ec5.db-wal -rw------- 600 events-47e20574-4420-4db2-9abd-09fa81b45ec5.db -rw------- 600 events-47e20574-4420-4db2-9abd-09fa81b45ec5.db-shm -rw------- 600 events-47e20574-4420-4db2-9abd-09fa81b45ec5.db-wal -rw------- 600 webhooker.db -rw------- 600 webhooker.db-shm -rw------- 600 webhooker.db-wal -rw------- 600 webhooker.lock ``` Directory still `0750`. ### Control: the same run on a pre-change build Same binary minus the `sqlite_open.go` change, fresh directory: ``` 750 . 644 webhooker.db 644 webhooker.db-shm 644 webhooker.db-wal 600 webhooker.lock ``` Then the fixed build opened that same directory: ``` 750 . 600 webhooker.db 600 webhooker.db-shm 600 webhooker.db-wal 600 webhooker.lock ``` Note the control confirms the trap was real: the pre-change build left the `-wal` and `-shm` world-readable too, so fixing only the main file would have fixed nothing. ### End to end, and restart `POST /webhook/{entrypoint}` answered 200 and the event was delivered: ``` "msg":"webhook event delivered to log target","delivery_id":"af2d9629-...", "target_name":"logsink","body":"{\"canary\":\"ISSUE-255-EVENT\"}" ``` Stopped, restarted against the same `DATA_DIR`: health check `ok`, a second event received and delivered, and every file — including the sidecars SQLite recreated on reopen — back at `0600`. The archive tier reopened with the rest. ### In the actual container Built the image and reproduced the deployment from the README, which is where the `0755` parent directory comes from: ``` drwxr-xr-x 755 user /tmp/.../dockerdata -rw------- 600 user /tmp/.../dockerdata/webhooker.db -rw------- 600 user /tmp/.../dockerdata/webhooker.db-shm -rw------- 600 user /tmp/.../dockerdata/webhooker.db-wal -rw------- 600 user /tmp/.../dockerdata/webhooker.lock ``` A world-listable parent, and the credentials are still unreadable. Every container was run `--rm` and `docker ps -a` is clean. ### Tests `internal/database/sqlite_mode_test.go` — the mode of the database *and* both sidecars for each of the three tiers, the tighten-on-open case, the reopen-after-restart case, that `SQLiteModeExisting` still does not materialize a file, and that the data directory is not world-accessible. Negative control: with the `sqlite_open.go` change stashed, the assertions fail on the main file and on both sidecars. #### The directory assertion is a property, not an exact mode The data-directory check was originally `assert.Equal(fs.FileMode(0o750), info.Mode().Perm())`. `MkdirAll` applies the ambient umask, so that pinned `make check` to the umask of whoever ran it. Measured: under `umask 077` it fails with `expected: 0x1e8, actual: 0x1c0` — 0750 against 0700. It now asserts the property that carries the security meaning: ```go assert.Zero( t, info.Mode().Perm()&0o007, "the data directory must not be world-accessible", ) ``` The group bits are deliberately left unasserted, since deployments may rely on them. Run both ways with `GOFLAGS=-count=1`: `make test` exits 0 under `umask 022` and under `umask 077`, and `TestMainDatabaseFilesAreOwnerOnly` passes in both. The file-mode assertions — the point of this PR — were already umask-independent and are unchanged. ## README The Docker section now carries the `DATA_DIR` ownership requirement where the bind mount is documented. Verified in a container rather than asserted: a `-v` source path Docker creates is `root:root`, the process runs as UID 1000, and it exits non-zero on the lock file before opening any database — ``` webhooker: locking data directory /var/lib/webhooker: open /var/lib/webhooker/webhooker.lock: permission denied ``` The `chown -R 1000:1000` that fixes this previously appeared only under Restore. Also verified and stated: a named volume does not have the problem, because the image creates `/var/lib/webhooker` owned by `webhooker` and Docker copies that onto a volume it initializes. The new text sits after the bind-address material from https://git.eeqj.de/sneak/webhooker/issues/268 and points at Restore rather than repeating it. ## Disclosures - While hunting for my own server process I ran `kill` against the output of a bare `pgrep -x webhooker`, which on this shared host matched 81 PIDs belonging to other sessions. All 81 were `<defunct>` zombies, on which `kill` is a no-op; I confirmed afterwards that the only live `webhooker` process was another session's, started after my command. Nothing was disrupted, but the command was wrong and I am flagging it. - `make docker` tags `webhooker:latest`, a name shared with every other session on this host. I retagged to `impl-255-webhooker:test` immediately and removed that tag afterwards; the shared `webhooker:latest` tag now points at my build. Not re-run since.

clawbot added 1 commit 2026-08-24 04:12:08 +02:00

Create every SQLite file 0600 (closes #255) ... 1230ae990e

webhooker.db holds target configuration in plaintext — bearer tokens,
API keys, Slack webhook URLs — and the session encryption key, and it
was created 0644. The 0750 data directory was therefore the only
barrier, and a Docker bind mount supplies that directory at 0755,
which removes it: every local user on the host could read every stored
credential.

The mode is settled in OpenSQLite, the single open path all three
tiers share, so the main database, the per-webhook event databases and
the archive databases are covered in one place.

0644 comes from SQLite itself: robust_open substitutes
SQLITE_DEFAULT_FILE_PERMISSIONS whenever it is handed mode 0, and
findCreateFileMode yields 0 for a main database opened by URI with no
`modeof` parameter. A chmod after opening would leave a window in
which the credentials are on disk world-readable, so OpenSQLite
creates the file itself at 0600 before the driver sees the path.

That also settles the WAL sidecars, which carry the same rows and
would otherwise leave the fix worthless. SQLite derives both from the
main database file — `-wal` through findCreateFileMode, which stats
the path with the suffix stripped, and `-shm` in unixOpenSharedMemory
from an fstat of the open database descriptor — so a main file at 0600
produces sidecars at 0600. Verified by stat rather than by reading the
driver: a pre-change build leaves webhooker.db, -wal and -shm all 644;
this one leaves all three 600, in a 0755 bind mount, for all three
tiers, with delivery and restart working.

Existing files are chmodded on open, so a directory an earlier build
left 0644 — including a developer's scratch directory — is fixed
without any migration machinery.

This is not encryption at rest. An unattended process needs a key it
can read without a human, so the key lands beside the data and an
attacker who can read the database can read it too.

The data directory stays 0750: the group bit may matter to a
deployment, and with the files at 0600 the directory is no longer the
barrier.

README: the Docker section now states the DATA_DIR ownership
requirement where the bind mount is documented. A `-v` source path
Docker creates is root:root, and the container runs as UID 1000, so it
fails to start on the lock file; the chown that fixes it appeared only
under Restore.

clawbot self-assigned this 2026-08-24 04:12:49 +02:00

clawbot added the needs-review label 2026-08-24 04:12:52 +02:00

clawbot referenced this pull request 2026-08-24 04:13:02 +02:00

SQLite files are created 0644 with plaintext credentials, and the documented Docker deployment supplies the parent directory 0755 #255

clawbot commented 2026-08-24 04:27:58 +02:00

Author

Collaborator

Copy Link

PASS.

Mechanism verified against modernc.org/sqlite v1.28.0 as pinned and it is exactly as described: robust_open substitutes SQLITE_DEFAULT_FILE_PERMISSIONS for mode 0; findCreateFileMode yields 0 for a URI-opened main DB with no modeof, and for SQLITE_OPEN_WAL|MAIN_JOURNAL stats the path with the suffix stripped; unixOpenSharedMemory passes st_mode & 0777 from an fstat of the open DB descriptor into robust_open. The sidecars are therefore covered structurally, not by a chmod that could miss a later file — and robust_open's trailing fchmod on a zero-length new file makes them umask-proof too. Reproduced 0644 on unmodified next across all three tiers and both sidecars; confirmed 0600 on the head for every file under umask 000 and inside a 0755 bind mount in the container; a busy-loop watcher over first boot, first write and lazy archive creation recorded zero instants wider than 0600. Negative control is live: five of the six new tests fail at base, each on the main file and on -wal and -shm.

Two non-blocking notes:

• internal/database/sqlite_mode_test.go:100 asserts the data directory is 0750. MkdirAll applies the umask, so make test now fails under umask 077 (measured: actual 0700). Pre-existing dataDirPerm behaviour, newly pinned by a test; the file-mode assertions themselves are umask-independent. perm & 0o007 == 0, or chmodding the directory, would remove the dependence.
• A stale archive-{uuid}.db left 0644 by an earlier build is tightened only on the next archive delivery. The idle sweep opens with SQLiteModeExisting, and with the default expiry=never it skips opening the file at all, so a dormant webhook's archive stays world-readable indefinitely (measured; it goes to 0600 the moment an event is delivered). Moot with no installed base; webhooker.db and events-*.db are both tightened at startup.

README checked against current next rather than as a diff: the new Docker text agrees with Restore step 4 and with the bind-address material from #268, both anchors resolve, and the quoted lock-file failure was reproduced verbatim in a container on a Docker-created root:root mount.

Disclosure: the negative control and a create-always-true probe were run with go test in throwaway copies outside the reviewed tree, never on it. During teardown I used a pkill -f scoped to my own unique scratch path; it matched only my own processes, including my own shell.

**PASS.** Mechanism verified against `modernc.org/sqlite v1.28.0` as pinned and it is exactly as described: `robust_open` substitutes `SQLITE_DEFAULT_FILE_PERMISSIONS` for mode 0; `findCreateFileMode` yields 0 for a URI-opened main DB with no `modeof`, and for `SQLITE_OPEN_WAL|MAIN_JOURNAL` stats the path with the suffix stripped; `unixOpenSharedMemory` passes `st_mode & 0777` from an `fstat` of the open DB descriptor into `robust_open`. The sidecars are therefore covered structurally, not by a chmod that could miss a later file — and `robust_open`'s trailing `fchmod` on a zero-length new file makes them umask-proof too. Reproduced `0644` on unmodified `next` across all three tiers and both sidecars; confirmed `0600` on the head for every file under `umask 000` and inside a `0755` bind mount in the container; a busy-loop watcher over first boot, first write and lazy archive creation recorded zero instants wider than `0600`. Negative control is live: five of the six new tests fail at base, each on the main file **and** on `-wal` **and** `-shm`. Two non-blocking notes: - `internal/database/sqlite_mode_test.go:100` asserts the data directory is `0750`. `MkdirAll` applies the umask, so `make test` now fails under `umask 077` (measured: actual `0700`). Pre-existing `dataDirPerm` behaviour, newly pinned by a test; the file-mode assertions themselves are umask-independent. `perm & 0o007 == 0`, or chmodding the directory, would remove the dependence. - A stale `archive-{uuid}.db` left `0644` by an earlier build is tightened only on the next archive **delivery**. The idle sweep opens with `SQLiteModeExisting`, and with the default `expiry=never` it skips opening the file at all, so a dormant webhook's archive stays world-readable indefinitely (measured; it goes to `0600` the moment an event is delivered). Moot with no installed base; `webhooker.db` and `events-*.db` are both tightened at startup. README checked against current `next` rather than as a diff: the new Docker text agrees with Restore step 4 and with the bind-address material from https://git.eeqj.de/sneak/webhooker/issues/268, both anchors resolve, and the quoted lock-file failure was reproduced verbatim in a container on a Docker-created `root:root` mount. Disclosure: the negative control and a `create`-always-true probe were run with `go test` in throwaway copies outside the reviewed tree, never on it. During teardown I used a `pkill -f` scoped to my own unique scratch path; it matched only my own processes, including my own shell.

clawbot referenced this pull request 2026-08-24 04:29:13 +02:00

GetDB can open the same event database twice, and closing the loser drops the winner's file locks #291

clawbot force-pushed issue-255-sqlite-file-mode from 1230ae990e to a5bc29f433 2026-08-24 04:32:28 +02:00 Compare

clawbot merged commit 322d9a6d6b into next 2026-08-24 04:33:40 +02:00

clawbot deleted branch issue-255-sqlite-file-mode 2026-08-24 04:33:41 +02:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

merge-ready

needs-checks

needs-rebase

needs-review

needs-rework

No Label needs-review

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

clawbot sneak

No Assignees clawbot

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/webhooker#287