Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
Closes#386804
The issue with coercing to `types.str` is that it's not mergeable, so
any declarations will result in an eval error like this:
error: The option `interactive.nodes.tmp.services.postgresql.settings.shared_preload_libraries' has conflicting definition values:
- In `/home/ma27/Projects/nixpkgs-hack/tmp.nix@node-tmp': "foo"
- In `/home/ma27/Projects/nixpkgs-hack/tmp.nix@node-tmp': "bar2"
Use `lib.mkForce value` or `lib.mkDefault value` to change the priority on any of these definitions.
Using a mergeable type (`types.comma`, i.e. a string, where all declarations
get joined with a comma as delimiter) fixes the problem.
Closes#385603
The problem described is that `wal-g` requires syscalls from `@resources`.
However, we don't have support for it in the module now and I don't
think it's reasonable to only support hardening adjustments for things
support by this module. Also, list is a bad datatype here since it
doesn't allow the level of customizations we need.
This is only for the syscall filterset since it's the option that's hard
to customize otherwise. For downstream configs, it's recommended to
adjust the hardening as needed in other cases.
Hence I decided to implement `services.postgresql.systemCallFilter` with
the following semantics:
* `systemCallFilter."~@resources" = true` adds `~@resources` to the
filterset.
* Setting this to `false` (e.g. in a downstream configuration using
`wal-g`) removes the entry `~@resources` from the filterset. In this
case it's sufficient since `@system-service` implies `@resources` and
the `~@resources` declaration after that discards that.
I decided to not implement logic about negations in here, but to keep
it rather simple by only allowing to set/unset entries.
As described in `systemd.exec(5)`, the ordering matters: e.g.
`@system-service` implies `@resources`, but `~@resources` _after_ that
reverts that. By default, the ordering of the keys is as follows:
* syscall groups (starting with `@`) come at first.
* negations of syscall groups (starting with `~@`) come after that.
* anything else at the end.
If further ordering is needed, it can be done like this:
```
{
services.postgresql.systemCallFilter."~@resources" = {
enable = true; # whether or not it's part of the final SystemCallFilter
priority = 23; # ordering priority in the filterset.
};
}
```
The lower the priority, the higher up the entry will be in the final
filterset.
In the case that the user wants to provide a custom data directory, we
need to grant `ReadWritePaths` for that directory. Previously this would
not happen when `/var/lib/postgresql` was used, because the condition
was not in fact checking for the default data directory, creating a gap
in then if-else scenario.
Fixes: #371680
