Hedgedoc hardening regresses Sqlite backend

[bgamari]

Describe the bug

The hardening measures of the hedgedoc systemd unit taken in https://github.com/NixOS/nixpkgs/pull/244941/commits/a70a3e61d77e64233b12e6ed678fbdf4b694c262 appear to break the service in at least some configurations.

Steps To Reproduce

Steps to reproduce the behavior:

1. Starting from a nixpkgs commit prior to the regressing commit: enable hedgedoc and create some content (the configuration of one affected environment can be found in https://gist.github.com/bgamari/b47127766dbbc4f2536dd290da85efbb)
2. Update to nixos-23.11
3. Observe that the service appears to start but the content is missing. The systemd log will contain messages of the form:

   Jan 12 21:21:32 schildkroete hedgedoc[3152719]: 2024-01-12T21:21:32.548Z info:         64.223.175.94 - - [12/Jan/2024:21:21:32 +0000] "GET /history HTTP/1.1" 200 - "https://edit.smart-cactus.org/" "Mozilla/5.0 (X11; Linux>
   Jan 12 21:21:32 schildkroete hedgedoc[3152719]: SequelizeDatabaseError: SQLITE_CANTOPEN: unable to open database file
   Jan 12 21:21:32 schildkroete hedgedoc[3152719]:     at Query.formatError (/nix/store/a513dgz9znzvgfjqzp7zyd1yxi6lxfgk-hedgedoc-1.9.9/node_modules/sequelize/lib/dialects/sqlite/query.js:422:16)
   Jan 12 21:21:32 schildkroete hedgedoc[3152719]:     at Query._handleQueryResponse (/nix/store/a513dgz9znzvgfjqzp7zyd1yxi6lxfgk-hedgedoc-1.9.9/node_modules/sequelize/lib/dialects/sqlite/query.js:73:18)
   Jan 12 21:21:32 schildkroete hedgedoc[3152719]:     at Statement.afterExecute (/nix/store/a513dgz9znzvgfjqzp7zyd1yxi6lxfgk-hedgedoc-1.9.9/node_modules/sequelize/lib/dialects/sqlite/query.js:250:31)
   Jan 12 21:21:32 schildkroete hedgedoc[3152719]:     at Statement.replacement (/nix/store/a513dgz9znzvgfjqzp7zyd1yxi6lxfgk-hedgedoc-1.9.9/node_modules/sqlite3/lib/trace.js:25:27)
   Jan 12 21:21:35 schildkroete hedgedoc[3152719]: 2024-01-12T21:21:35.361Z info:         64.223.175.94 - - [12/Jan/2024:21:21:35 +0000] "GET /build/79157b10fa84021a381d04676ffbfb27b8e13595ce15c342d0d40801b375f553.woff HTTP/>

Expected behavior

Hedgedoc will continue to operate as expected.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

Notify maintainers

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
output here

---

Add a :+1: reaction to issues you find important.

[bgamari]

For the record, the ownership of the backend database appears to be sensible:

# ls -ld /var/lib/codimd/db.codimd.sqlite
-rw-r--r-- 1 hedgedoc hedgedoc 10043392 Jan 12 21:15 /var/lib/codimd/db.codimd.sqlite

[bgamari]

FWIW, I found that moving /var/lib/codimd/db.codimd.sqlite to /var/lib/hedgedoc/db.hedgedoc.sqlite (and updating services.hedgedoc.settings.db.storage) avoids the issue.

[eclairevoyant]

Yeah this is expected when using ProtectSystem="strict", see https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html

[h7x4]

The database path is supposed to be added to ReadWritePaths, whitelisting it from ProtectSystem. There was no default value provided for settings.db.storage before #244941, so I don't think the updated example (and now default) of /var/lib/${name}/db.${name}.sqlite -> /var/lib/${name}/db.sqlite should be causing any issues.

I noticed that it only gets added when using settings.db.storage, and not with settings.dbUrl. I believe there's a case where if you had configured your database by dbURL = "sqlite:/var/lib/codimd/db.codimd.sqlite", it would be broken in this way. But looking at config from the gist, that doesn't seem to be what's happening here.

@bgamari Do you have the value of ReadWritePaths on the broken setup readily available? If not, I'll set up a reproduction.

[SuperSandro2000]

Can you please provide a patch after you figured out what's wrong here? I do not really have the time to look into this in detail :/