nixos/postgresql/citus: fix syscall filter and add test

[jflanglois]

This fixes the citus extension for postgresql. Without this, the database will crash on start because the extension uses getpriority and setpriority syscalls. The ~@privileged @resources filter breaks those calls. This also adds automated tests for citus.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[jflanglois]

Build failure looks related to rustc, so I assume this is due to the state of staging.

[wolfgangwalther]

So, in #355010 we didn't add a whole new test on purpose - because this won't scale for many extensions. We can't add a new VM test for each of them. But I think we also can't test them together, otherwise the granted exceptions here might overlay each other.

At the same time - we should really test this. So we need a VM test.

I don't really have a solution, but I do think that a VM test for citus is generally a good idea, especially if we consider that this test could be extended to test multiple machines setting up a citus cluster in the future.

TLDR: I'm OK with adding another test here.

[jflanglois]

Right I agree with a multi-node test, but would rather do that on top of master when staging is merged

[jflanglois]

This also makes me think: I wonder if the hardening should be made more configurable in the module? It seems like extensions could easily hit a blocked syscall after an update and this was difficult to debug for me because there were no logs—I only looked at hardening options because postgresql started fine when run manually.

[Ma27]

It seems like extensions could easily hit a blocked syscall after an update and this was difficult to debug for me because there were no logs

Aren't these logged to the kernel log?
I don't recall where exactly, but I'm pretty sure it's written somewhere - for syscalls at least.

I wonder if the hardening should be made more configurable in the module

See #344925 (comment) for my rationale on why it's implemented the way it currently is.

So, in #355010 we didn't add a whole new test on purpose - because this won't scale for many extensions. We can't add a new VM test for each of them. But I think we also can't test them together, otherwise the granted exceptions here might overlay each other.

Agreed. For the time being, my suggestion would be to add VM tests when the need arises (i.e. when we have to adjust the hardening for instance).

[wolfgangwalther]

Build failure looks related to rustc, so I assume this is due to the state of staging.

I am building on staging with very low resources allocated - so this might take a while. Will still look at this.

[Ma27]

Successfully built the test. LGTM from my side.

[jflanglois]

Thanks y'all

[Ma27]

I figured that it's probably reasonable to backport this to 24.11 as well: #383933