nixpkgs/nixos/modules/services/databases/postgresql.nix

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

883 lines
32 KiB
Nix
Raw Normal View History

{
config,
lib,
pkgs,
...
}:
let
inherit (lib)
any
attrValues
concatMapStrings
concatStringsSep
const
elem
escapeShellArgs
nixos/postgresql: allow customisations of SystemCallFilter 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.
2025-03-02 11:06:49 +01:00
filter
filterAttrs
nixos/postgresql: allow customisations of SystemCallFilter 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.
2025-03-02 11:06:49 +01:00
getAttr
getName
nixos/postgresql: allow customisations of SystemCallFilter 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.
2025-03-02 11:06:49 +01:00
hasPrefix
isString
literalExpression
mapAttrs
mapAttrsToList
mkAfter
mkBefore
mkDefault
mkEnableOption
mkIf
mkMerge
mkOption
mkPackageOption
mkRemovedOptionModule
mkRenamedOptionModule
optionalString
nixos/postgresql: allow customisations of SystemCallFilter 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.
2025-03-02 11:06:49 +01:00
pipe
sortProperties
types
versionAtLeast
warn
;
cfg = config.services.postgresql;
# ensure that
# services.postgresql = {
# enableJIT = true;
# package = pkgs.postgresql_<major>;
# };
# works.
basePackage = if cfg.enableJIT then cfg.package.withJIT else cfg.package.withoutJIT;
postgresql = if cfg.extensions == [ ] then basePackage else basePackage.withPackages cfg.extensions;
toStr =
value:
if true == value then
"yes"
else if false == value then
"no"
else if isString value then
"'${lib.replaceStrings [ "'" ] [ "''" ] value}'"
else
builtins.toString value;
# The main PostgreSQL configuration file.
configFile = pkgs.writeTextDir "postgresql.conf" (
concatStringsSep "\n" (
mapAttrsToList (n: v: "${n} = ${toStr v}") (filterAttrs (const (x: x != null)) cfg.settings)
)
);
configFileCheck = pkgs.runCommand "postgresql-configfile-check" { } ''
${cfg.package}/bin/postgres -D${configFile} -C config_file >/dev/null
touch $out
'';
groupAccessAvailable = versionAtLeast cfg.finalPackage.version "11.0";
extensionNames = map getName postgresql.installedExtensions;
extensionInstalled = extension: elem extension extensionNames;
in
{
imports = [
(mkRemovedOptionModule [
"services"
"postgresql"
"extraConfig"
] "Use services.postgresql.settings instead.")
(mkRemovedOptionModule [
"services"
"postgresql"
"recoveryConfig"
] "PostgreSQL v12+ doesn't support recovery.conf.")
(mkRenamedOptionModule
[ "services" "postgresql" "logLinePrefix" ]
[ "services" "postgresql" "settings" "log_line_prefix" ]
)
(mkRenamedOptionModule
[ "services" "postgresql" "port" ]
[ "services" "postgresql" "settings" "port" ]
)
(mkRenamedOptionModule
[ "services" "postgresql" "extraPlugins" ]
[ "services" "postgresql" "extensions" ]
)
];
###### interface
options = {
services.postgresql = {
enable = mkEnableOption "PostgreSQL Server";
enableJIT = mkEnableOption "JIT support";
package = mkPackageOption pkgs "postgresql" {
example = "postgresql_15";
};
finalPackage = mkOption {
type = types.package;
readOnly = true;
default = postgresql;
defaultText = "with config.services.postgresql; package.withPackages extensions";
description = ''
The postgresql package that will effectively be used in the system.
It consists of the base package with plugins applied to it.
'';
};
nixos/postgresql: allow customisations of SystemCallFilter 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.
2025-03-02 11:06:49 +01:00
systemCallFilter = mkOption {
type = types.attrsOf (
types.coercedTo types.bool (enable: { inherit enable; }) (
types.submodule (
{ name, ... }:
{
options = {
enable = mkEnableOption "${name} in postgresql's syscall filter";
priority = mkOption {
default =
if hasPrefix "@" name then
500
else if hasPrefix "~@" name then
1000
else
1500;
defaultText = literalExpression ''
if hasPrefix "@" name then 500 else if hasPrefix "~@" name then 1000 else 1500
'';
type = types.int;
description = ''
Set the priority of the system call filter setting. Later declarations
override earlier ones, e.g.
```ini
[Service]
SystemCallFilter=~read write
SystemCallFilter=write
```
results in a service where _only_ `read` is not allowed.
The ordering in the unit file is controlled by this option: the higher
the number, the later it will be added to the filterset.
By default, depending on the prefix a priority is assigned: usually, call-groups
(starting with `@`) are used to allow/deny a larger set of syscalls and later
on single syscalls are configured for exceptions. Hence, syscall groups
and negative groups are placed before individual syscalls by default.
'';
};
};
}
)
)
);
defaultText = literalExpression ''
{
"@system-service" = true;
"~@privileged" = true;
"~@resources" = true;
}
'';
description = ''
Configures the syscall filter for `postgresql.service`. The keys are
declarations for `SystemCallFilter` as described in {manpage}`systemd.exec(5)`.
The value is a boolean: `true` adds the attribute name to the syscall filter-set,
`false` doesn't. This is done to allow downstream configurations to turn off
restrictions made here. E.g. with
```nix
{
services.postgresql.systemCallFilter."~@resources" = false;
}
```
it's possible to remove the restriction on `@resources` (keep in mind that
`@system-service` implies `@resources`).
As described in the section for [](#opt-services.postgresql.systemCallFilter._name_.priority),
the ordering matters. Hence, it's also possible to specify customizations with
```nix
{
services.postgresql.systemCallFilter = {
"foobar" = { enable = true; priority = 23; };
};
}
```
[](#opt-services.postgresql.systemCallFilter._name_.enable) is the flag whether
or not it will be added to the `SystemCallFilter` of `postgresql.service`.
Settings with a higher priority are added after filter settings with a lower
priority. Hence, syscall groups with a higher priority can discard declarations
with a lower priority.
By default, syscall groups (i.e. attribute names starting with `@`) are added
_before_ negated groups (i.e. `~@` as prefix) _before_ syscall names
and negations.
'';
};
checkConfig = mkOption {
type = types.bool;
default = true;
description = "Check the syntax of the configuration file at compile time";
};
dataDir = mkOption {
2013-10-30 17:37:45 +01:00
type = types.path;
defaultText = literalExpression ''"/var/lib/postgresql/''${config.services.postgresql.package.psqlSchema}"'';
example = "/var/lib/postgresql/15";
description = ''
The data directory for PostgreSQL. If left as the default value
this directory will automatically be created before the PostgreSQL server starts, otherwise
the sysadmin is responsible for ensuring the directory exists with appropriate ownership
and permissions.
'';
};
authentication = mkOption {
2013-10-30 17:37:45 +01:00
type = types.lines;
default = "";
description = ''
Defines how users authenticate themselves to the server. See the
[PostgreSQL documentation for pg_hba.conf](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html)
for details on the expected format of this option. By default,
peer based authentication will be used for users connecting
via the Unix socket, and md5 password authentication will be
used for users connecting via TCP. Any added rules will be
inserted above the default rules. If you'd like to replace the
default rules entirely, you can use `lib.mkForce` in your
module.
'';
};
identMap = mkOption {
2013-10-30 17:37:45 +01:00
type = types.lines;
default = "";
example = ''
map-name-0 system-username-0 database-username-0
map-name-1 system-username-1 database-username-1
'';
description = ''
Defines the mapping from system users to database users.
See the [auth doc](https://postgresql.org/docs/current/auth-username-maps.html).
There is a default map "postgres" which is used for local peer authentication
as the postgres superuser role.
For example, to allow the root user to login as the postgres superuser, add:
```
postgres root postgres
```
'';
};
initdbArgs = mkOption {
type = with types; listOf str;
default = [ ];
example = [
"--data-checksums"
"--allow-group-access"
];
description = ''
2020-02-15 19:16:41 +01:00
Additional arguments passed to `initdb` during data dir
initialisation.
'';
};
initialScript = mkOption {
type = types.nullOr types.path;
2013-10-30 17:37:45 +01:00
default = null;
example = literalExpression ''
pkgs.writeText "init-sql-script" '''
alter user postgres with password 'myPassword';
''';'';
description = ''
A file containing SQL statements to execute on first startup.
'';
};
ensureDatabases = mkOption {
type = types.listOf types.str;
default = [ ];
description = ''
Ensures that the specified databases exist.
This option will never delete existing databases, especially not when the value of this
option is changed. This means that databases created once through this option or
otherwise have to be removed manually.
'';
example = [
"gitea"
"nextcloud"
];
};
ensureUsers = mkOption {
type = types.listOf (
types.submodule {
options = {
name = mkOption {
type = types.str;
description = ''
Name of the user to ensure.
'';
};
nixos/postgresql: drop ensurePermissions, fix ensureUsers for postgresql15 Closes #216989 First of all, a bit of context: in PostgreSQL, newly created users don't have the CREATE privilege on the public schema of a database even with `ALL PRIVILEGES` granted via `ensurePermissions` which is how most of the DB users are currently set up "declaratively"[1]. This means e.g. a freshly deployed Nextcloud service will break early because Nextcloud itself cannot CREATE any tables in the public schema anymore. The other issue here is that `ensurePermissions` is a mere hack. It's effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how a value is substituted in a query. You'd have to parse a subset of SQL to actually know which object are permissions granted to for a user). After analyzing the existing modules I realized that in every case with a single exception[2] the UNIX system user is equal to the db user is equal to the db name and I don't see a compelling reason why people would change that in 99% of the cases. In fact, some modules would even break if you'd change that because the declarations of the system user & the db user are mixed up[3]. So I decided to go with something new which restricts the ways to use `ensure*` options rather than expanding those[4]. Effectively this means that * The DB user _must_ be equal to the DB name. * Permissions are granted via `ensureDBOwnerhip` for an attribute-set in `ensureUsers`. That way, the user is actually the owner and can perform `CREATE`. * For such a postgres user, a database must be declared in `ensureDatabases`. For anything else, a custom state management should be implemented. This can either be `initialScript`, doing it manual, outside of the module or by implementing proper state management for postgresql[5], but the current state of `ensure*` isn't even declarative, but a convergent tool which is what Nix actually claims to _not_ do. Regarding existing setups: there are effectively two options: * Leave everything as-is (assuming that system user == db user == db name): then the DB user will automatically become the DB owner and everything else stays the same. * Drop the `createDatabase = true;` declarations: nothing will change because a removal of `ensure*` statements is ignored, so it doesn't matter at all whether this option is kept after the first deploy (and later on you'd usually restore from backups anyways). The DB user isn't the owner of the DB then, but for an existing setup this is irrelevant because CREATE on the public schema isn't revoked from existing users (only not granted for new users). [1] not really declarative though because removals of these statements are simply ignored for instance: https://github.com/NixOS/nixpkgs/issues/206467 [2] `services.invidious`: I removed the `ensure*` part temporarily because it IMHO falls into the category "manage the state on your own" (see the commit message). See also https://github.com/NixOS/nixpkgs/pull/265857 [3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";` [4] As opposed to other changes that are considered a potential fix, but also add more things like collation for DBs or passwords that are _never_ touched again when changing those. [5] As suggested in e.g. https://github.com/NixOS/nixpkgs/issues/206467
2023-11-08 12:50:09 +01:00
ensureDBOwnership = mkOption {
type = types.bool;
default = false;
description = ''
Grants the user ownership to a database with the same name.
This database must be defined manually in
[](#opt-services.postgresql.ensureDatabases).
'';
};
ensureClauses = mkOption {
description = ''
An attrset of clauses to grant to the user. Under the hood this uses the
[ALTER USER syntax](https://www.postgresql.org/docs/current/sql-alteruser.html) for each attrName where
the attrValue is true in the attrSet:
`ALTER USER user.name WITH attrName`
'';
example = literalExpression ''
{
superuser = true;
createrole = true;
createdb = true;
}
'';
default = { };
defaultText = lib.literalMD ''
The default, `null`, means that the user created will have the default permissions assigned by PostgreSQL. Subsequent server starts will not set or unset the clause, so imperative changes are preserved.
'';
type = types.submodule {
options =
let
defaultText = lib.literalMD ''
`null`: do not set. For newly created roles, use PostgreSQL's default. For existing roles, do not touch this clause.
'';
in
{
superuser = mkOption {
type = types.nullOr types.bool;
description = ''
Grants the user, created by the ensureUser attr, superuser permissions. From the postgres docs:
A database superuser bypasses all permission checks,
except the right to log in. This is a dangerous privilege
and should not be used carelessly; it is best to do most
of your work as a role that is not a superuser. To create
a new database superuser, use CREATE ROLE name SUPERUSER.
You must do this as a role that is already a superuser.
More information on postgres roles can be found [here](https://www.postgresql.org/docs/current/role-attributes.html)
'';
default = null;
inherit defaultText;
};
createrole = mkOption {
type = types.nullOr types.bool;
description = ''
Grants the user, created by the ensureUser attr, createrole permissions. From the postgres docs:
A role must be explicitly given permission to create more
roles (except for superusers, since those bypass all
permission checks). To create such a role, use CREATE
ROLE name CREATEROLE. A role with CREATEROLE privilege
can alter and drop other roles, too, as well as grant or
revoke membership in them. However, to create, alter,
drop, or change membership of a superuser role, superuser
status is required; CREATEROLE is insufficient for that.
More information on postgres roles can be found [here](https://www.postgresql.org/docs/current/role-attributes.html)
'';
default = null;
inherit defaultText;
};
createdb = mkOption {
type = types.nullOr types.bool;
description = ''
Grants the user, created by the ensureUser attr, createdb permissions. From the postgres docs:
A role must be explicitly given permission to create
databases (except for superusers, since those bypass all
permission checks). To create such a role, use CREATE
ROLE name CREATEDB.
More information on postgres roles can be found [here](https://www.postgresql.org/docs/current/role-attributes.html)
'';
default = null;
inherit defaultText;
};
"inherit" = mkOption {
type = types.nullOr types.bool;
description = ''
Grants the user created inherit permissions. From the postgres docs:
A role is given permission to inherit the privileges of
roles it is a member of, by default. However, to create a
role without the permission, use CREATE ROLE name
NOINHERIT.
More information on postgres roles can be found [here](https://www.postgresql.org/docs/current/role-attributes.html)
'';
default = null;
inherit defaultText;
};
login = mkOption {
type = types.nullOr types.bool;
description = ''
Grants the user, created by the ensureUser attr, login permissions. From the postgres docs:
Only roles that have the LOGIN attribute can be used as
the initial role name for a database connection. A role
with the LOGIN attribute can be considered the same as a
database user. To create a role with login privilege,
use either:
CREATE ROLE name LOGIN; CREATE USER name;
(CREATE USER is equivalent to CREATE ROLE except that
CREATE USER includes LOGIN by default, while CREATE ROLE
does not.)
More information on postgres roles can be found [here](https://www.postgresql.org/docs/current/role-attributes.html)
'';
default = null;
inherit defaultText;
};
replication = mkOption {
type = types.nullOr types.bool;
description = ''
Grants the user, created by the ensureUser attr, replication permissions. From the postgres docs:
A role must explicitly be given permission to initiate
streaming replication (except for superusers, since those
bypass all permission checks). A role used for streaming
replication must have LOGIN permission as well. To create
such a role, use CREATE ROLE name REPLICATION LOGIN.
More information on postgres roles can be found [here](https://www.postgresql.org/docs/current/role-attributes.html)
'';
default = null;
inherit defaultText;
};
bypassrls = mkOption {
type = types.nullOr types.bool;
description = ''
Grants the user, created by the ensureUser attr, replication permissions. From the postgres docs:
A role must be explicitly given permission to bypass
every row-level security (RLS) policy (except for
superusers, since those bypass all permission checks). To
create such a role, use CREATE ROLE name BYPASSRLS as a
superuser.
More information on postgres roles can be found [here](https://www.postgresql.org/docs/current/role-attributes.html)
'';
default = null;
inherit defaultText;
};
};
};
};
};
}
);
default = [ ];
description = ''
nixos/postgresql: drop ensurePermissions, fix ensureUsers for postgresql15 Closes #216989 First of all, a bit of context: in PostgreSQL, newly created users don't have the CREATE privilege on the public schema of a database even with `ALL PRIVILEGES` granted via `ensurePermissions` which is how most of the DB users are currently set up "declaratively"[1]. This means e.g. a freshly deployed Nextcloud service will break early because Nextcloud itself cannot CREATE any tables in the public schema anymore. The other issue here is that `ensurePermissions` is a mere hack. It's effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how a value is substituted in a query. You'd have to parse a subset of SQL to actually know which object are permissions granted to for a user). After analyzing the existing modules I realized that in every case with a single exception[2] the UNIX system user is equal to the db user is equal to the db name and I don't see a compelling reason why people would change that in 99% of the cases. In fact, some modules would even break if you'd change that because the declarations of the system user & the db user are mixed up[3]. So I decided to go with something new which restricts the ways to use `ensure*` options rather than expanding those[4]. Effectively this means that * The DB user _must_ be equal to the DB name. * Permissions are granted via `ensureDBOwnerhip` for an attribute-set in `ensureUsers`. That way, the user is actually the owner and can perform `CREATE`. * For such a postgres user, a database must be declared in `ensureDatabases`. For anything else, a custom state management should be implemented. This can either be `initialScript`, doing it manual, outside of the module or by implementing proper state management for postgresql[5], but the current state of `ensure*` isn't even declarative, but a convergent tool which is what Nix actually claims to _not_ do. Regarding existing setups: there are effectively two options: * Leave everything as-is (assuming that system user == db user == db name): then the DB user will automatically become the DB owner and everything else stays the same. * Drop the `createDatabase = true;` declarations: nothing will change because a removal of `ensure*` statements is ignored, so it doesn't matter at all whether this option is kept after the first deploy (and later on you'd usually restore from backups anyways). The DB user isn't the owner of the DB then, but for an existing setup this is irrelevant because CREATE on the public schema isn't revoked from existing users (only not granted for new users). [1] not really declarative though because removals of these statements are simply ignored for instance: https://github.com/NixOS/nixpkgs/issues/206467 [2] `services.invidious`: I removed the `ensure*` part temporarily because it IMHO falls into the category "manage the state on your own" (see the commit message). See also https://github.com/NixOS/nixpkgs/pull/265857 [3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";` [4] As opposed to other changes that are considered a potential fix, but also add more things like collation for DBs or passwords that are _never_ touched again when changing those. [5] As suggested in e.g. https://github.com/NixOS/nixpkgs/issues/206467
2023-11-08 12:50:09 +01:00
Ensures that the specified users exist.
The PostgreSQL users will be identified using peer authentication. This authenticates the Unix user with the
same name only, and that without the need for a password.
nixos/postgresql: drop ensurePermissions, fix ensureUsers for postgresql15 Closes #216989 First of all, a bit of context: in PostgreSQL, newly created users don't have the CREATE privilege on the public schema of a database even with `ALL PRIVILEGES` granted via `ensurePermissions` which is how most of the DB users are currently set up "declaratively"[1]. This means e.g. a freshly deployed Nextcloud service will break early because Nextcloud itself cannot CREATE any tables in the public schema anymore. The other issue here is that `ensurePermissions` is a mere hack. It's effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how a value is substituted in a query. You'd have to parse a subset of SQL to actually know which object are permissions granted to for a user). After analyzing the existing modules I realized that in every case with a single exception[2] the UNIX system user is equal to the db user is equal to the db name and I don't see a compelling reason why people would change that in 99% of the cases. In fact, some modules would even break if you'd change that because the declarations of the system user & the db user are mixed up[3]. So I decided to go with something new which restricts the ways to use `ensure*` options rather than expanding those[4]. Effectively this means that * The DB user _must_ be equal to the DB name. * Permissions are granted via `ensureDBOwnerhip` for an attribute-set in `ensureUsers`. That way, the user is actually the owner and can perform `CREATE`. * For such a postgres user, a database must be declared in `ensureDatabases`. For anything else, a custom state management should be implemented. This can either be `initialScript`, doing it manual, outside of the module or by implementing proper state management for postgresql[5], but the current state of `ensure*` isn't even declarative, but a convergent tool which is what Nix actually claims to _not_ do. Regarding existing setups: there are effectively two options: * Leave everything as-is (assuming that system user == db user == db name): then the DB user will automatically become the DB owner and everything else stays the same. * Drop the `createDatabase = true;` declarations: nothing will change because a removal of `ensure*` statements is ignored, so it doesn't matter at all whether this option is kept after the first deploy (and later on you'd usually restore from backups anyways). The DB user isn't the owner of the DB then, but for an existing setup this is irrelevant because CREATE on the public schema isn't revoked from existing users (only not granted for new users). [1] not really declarative though because removals of these statements are simply ignored for instance: https://github.com/NixOS/nixpkgs/issues/206467 [2] `services.invidious`: I removed the `ensure*` part temporarily because it IMHO falls into the category "manage the state on your own" (see the commit message). See also https://github.com/NixOS/nixpkgs/pull/265857 [3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";` [4] As opposed to other changes that are considered a potential fix, but also add more things like collation for DBs or passwords that are _never_ touched again when changing those. [5] As suggested in e.g. https://github.com/NixOS/nixpkgs/issues/206467
2023-11-08 12:50:09 +01:00
This option will never delete existing users or remove DB ownership of databases
once granted with `ensureDBOwnership = true;`. This means that this must be
cleaned up manually when changing after changing the config in here.
'';
example = literalExpression ''
[
{
name = "nextcloud";
}
{
name = "superuser";
nixos/postgresql: drop ensurePermissions, fix ensureUsers for postgresql15 Closes #216989 First of all, a bit of context: in PostgreSQL, newly created users don't have the CREATE privilege on the public schema of a database even with `ALL PRIVILEGES` granted via `ensurePermissions` which is how most of the DB users are currently set up "declaratively"[1]. This means e.g. a freshly deployed Nextcloud service will break early because Nextcloud itself cannot CREATE any tables in the public schema anymore. The other issue here is that `ensurePermissions` is a mere hack. It's effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how a value is substituted in a query. You'd have to parse a subset of SQL to actually know which object are permissions granted to for a user). After analyzing the existing modules I realized that in every case with a single exception[2] the UNIX system user is equal to the db user is equal to the db name and I don't see a compelling reason why people would change that in 99% of the cases. In fact, some modules would even break if you'd change that because the declarations of the system user & the db user are mixed up[3]. So I decided to go with something new which restricts the ways to use `ensure*` options rather than expanding those[4]. Effectively this means that * The DB user _must_ be equal to the DB name. * Permissions are granted via `ensureDBOwnerhip` for an attribute-set in `ensureUsers`. That way, the user is actually the owner and can perform `CREATE`. * For such a postgres user, a database must be declared in `ensureDatabases`. For anything else, a custom state management should be implemented. This can either be `initialScript`, doing it manual, outside of the module or by implementing proper state management for postgresql[5], but the current state of `ensure*` isn't even declarative, but a convergent tool which is what Nix actually claims to _not_ do. Regarding existing setups: there are effectively two options: * Leave everything as-is (assuming that system user == db user == db name): then the DB user will automatically become the DB owner and everything else stays the same. * Drop the `createDatabase = true;` declarations: nothing will change because a removal of `ensure*` statements is ignored, so it doesn't matter at all whether this option is kept after the first deploy (and later on you'd usually restore from backups anyways). The DB user isn't the owner of the DB then, but for an existing setup this is irrelevant because CREATE on the public schema isn't revoked from existing users (only not granted for new users). [1] not really declarative though because removals of these statements are simply ignored for instance: https://github.com/NixOS/nixpkgs/issues/206467 [2] `services.invidious`: I removed the `ensure*` part temporarily because it IMHO falls into the category "manage the state on your own" (see the commit message). See also https://github.com/NixOS/nixpkgs/pull/265857 [3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";` [4] As opposed to other changes that are considered a potential fix, but also add more things like collation for DBs or passwords that are _never_ touched again when changing those. [5] As suggested in e.g. https://github.com/NixOS/nixpkgs/issues/206467
2023-11-08 12:50:09 +01:00
ensureDBOwnership = true;
}
]
'';
};
enableTCPIP = mkOption {
2013-10-30 17:37:45 +01:00
type = types.bool;
default = false;
description = ''
Whether PostgreSQL should listen on all network interfaces.
If disabled, the database can only be accessed via its Unix
domain socket or via TCP connections to localhost.
'';
};
extensions = mkOption {
type = with types; coercedTo (listOf path) (path: _ignorePg: path) (functionTo (listOf path));
default = _: [ ];
example = literalExpression "ps: with ps; [ postgis pg_repack ]";
description = ''
List of PostgreSQL extensions to install.
'';
};
settings = mkOption {
type =
with types;
submodule {
freeformType = attrsOf (oneOf [
bool
float
int
str
]);
options = {
shared_preload_libraries = mkOption {
type = nullOr (coercedTo (listOf str) (concatStringsSep ",") commas);
default = null;
example = literalExpression ''[ "auto_explain" "anon" ]'';
description = ''
List of libraries to be preloaded.
'';
};
log_line_prefix = mkOption {
type = types.str;
default = "[%p] ";
example = "%m [%p] ";
description = ''
A printf-style string that is output at the beginning of each log line.
Upstream default is `'%m [%p] '`, i.e. it includes the timestamp. We do
not include the timestamp, because journal has it anyway.
'';
};
port = mkOption {
type = types.port;
default = 5432;
description = ''
The port on which PostgreSQL listens.
'';
};
};
};
default = { };
description = ''
PostgreSQL configuration. Refer to
<https://www.postgresql.org/docs/current/config-setting.html#CONFIG-SETTING-CONFIGURATION-FILE>
for an overview of `postgresql.conf`.
::: {.note}
String values will automatically be enclosed in single quotes. Single quotes will be
escaped with two single quotes as described by the upstream documentation linked above.
:::
'';
example = literalExpression ''
{
log_connections = true;
log_statement = "all";
2023-07-27 11:48:25 +02:00
logging_collector = true;
log_disconnections = true;
log_destination = lib.mkForce "syslog";
}
'';
};
superUser = mkOption {
type = types.str;
default = "postgres";
internal = true;
readOnly = true;
description = ''
PostgreSQL superuser account to use for various operations. Internal since changing
this value would lead to breakage while setting up databases.
'';
};
};
};
###### implementation
config = mkIf cfg.enable {
assertions = map (
{ name, ensureDBOwnership, ... }:
{
assertion = ensureDBOwnership -> elem name cfg.ensureDatabases;
message = ''
For each database user defined with `services.postgresql.ensureUsers` and
`ensureDBOwnership = true;`, a database with the same name must be defined
in `services.postgresql.ensureDatabases`.
Offender: ${name} has not been found among databases.
'';
}
) cfg.ensureUsers;
services.postgresql.settings = {
hba_file = "${pkgs.writeText "pg_hba.conf" cfg.authentication}";
ident_file = "${pkgs.writeText "pg_ident.conf" cfg.identMap}";
log_destination = "stderr";
listen_addresses = if cfg.enableTCPIP then "*" else "localhost";
jit = mkDefault (if cfg.enableJIT then "on" else "off");
};
2021-12-03 01:00:48 +01:00
services.postgresql.package =
let
mkThrow = ver: throw "postgresql_${ver} was removed, please upgrade your postgresql version.";
mkWarn =
ver:
warn ''
The postgresql package is not pinned and selected automatically by
2024-11-16 20:59:04 -05:00
`system.stateVersion`. Right now this is `pkgs.postgresql_${ver}`, the
oldest postgresql version available and thus the next that will be
removed when EOL on the next stable cycle.
See also https://endoflife.date/postgresql
'';
base =
if versionAtLeast config.system.stateVersion "24.11" then
pkgs.postgresql_16
else if versionAtLeast config.system.stateVersion "23.11" then
2023-09-09 18:11:51 +01:00
pkgs.postgresql_15
else if versionAtLeast config.system.stateVersion "22.05" then
pkgs.postgresql_14
else if versionAtLeast config.system.stateVersion "21.11" then
mkWarn "13" pkgs.postgresql_13
else if versionAtLeast config.system.stateVersion "20.03" then
mkThrow "11"
else if versionAtLeast config.system.stateVersion "17.09" then
mkThrow "9_6"
else
mkThrow "9_5";
2021-12-03 01:00:48 +01:00
in
# Note: when changing the default, make it conditional on
# system.stateVersion to maintain compatibility with existing
# systems!
mkDefault (if cfg.enableJIT then base.withJIT else base);
services.postgresql.dataDir = mkDefault "/var/lib/postgresql/${cfg.package.psqlSchema}";
services.postgresql.authentication = mkMerge [
(mkBefore "# Generated file; do not edit!")
(mkAfter ''
# default value of services.postgresql.authentication
local all postgres peer map=postgres
local all all peer
host all all 127.0.0.1/32 md5
host all all ::1/128 md5
'')
];
# The default allows to login with the same database username as the current system user.
# This is the default for peer authentication without a map, but needs to be made explicit
# once a map is used.
services.postgresql.identMap = mkAfter ''
postgres postgres postgres
'';
nixos/postgresql: allow customisations of SystemCallFilter 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.
2025-03-02 11:06:49 +01:00
services.postgresql.systemCallFilter = mkMerge [
(mapAttrs (const mkDefault) {
"@system-service" = true;
"~@privileged" = true;
"~@resources" = true;
})
(mkIf (any extensionInstalled [ "plv8" ]) {
"@pkey" = true;
})
(mkIf (any extensionInstalled [ "citus" ]) {
"getpriority" = true;
"setpriority" = true;
})
];
users.users.postgres = {
name = "postgres";
uid = config.ids.uids.postgres;
group = "postgres";
description = "PostgreSQL server user";
2018-09-26 12:11:28 +01:00
home = "${cfg.dataDir}";
useDefaultShell = true;
};
users.groups.postgres.gid = config.ids.gids.postgres;
environment.systemPackages = [ cfg.finalPackage ];
environment.pathsToLink = [
"/share/postgresql"
];
system.checks = lib.optional (
cfg.checkConfig && pkgs.stdenv.hostPlatform == pkgs.stdenv.buildPlatform
) configFileCheck;
systemd.services.postgresql = {
2012-12-18 13:40:04 +01:00
description = "PostgreSQL Server";
wantedBy = [ "multi-user.target" ];
2012-12-18 13:40:04 +01:00
after = [ "network.target" ];
environment.PGDATA = cfg.dataDir;
path = [ cfg.finalPackage ];
preStart = ''
if ! test -e ${cfg.dataDir}/PG_VERSION; then
# Cleanup the data directory.
2016-02-09 03:07:23 +03:00
rm -f ${cfg.dataDir}/*.conf
# Initialise the database.
initdb -U ${cfg.superUser} ${escapeShellArgs cfg.initdbArgs}
2016-02-09 03:07:23 +03:00
# See postStart!
touch "${cfg.dataDir}/.first_startup"
fi
ln -sfn "${configFile}/postgresql.conf" "${cfg.dataDir}/postgresql.conf"
2016-02-09 03:07:23 +03:00
'';
# Wait for PostgreSQL to be ready to accept connections.
postStart =
nixos/postgresql: drop ensurePermissions, fix ensureUsers for postgresql15 Closes #216989 First of all, a bit of context: in PostgreSQL, newly created users don't have the CREATE privilege on the public schema of a database even with `ALL PRIVILEGES` granted via `ensurePermissions` which is how most of the DB users are currently set up "declaratively"[1]. This means e.g. a freshly deployed Nextcloud service will break early because Nextcloud itself cannot CREATE any tables in the public schema anymore. The other issue here is that `ensurePermissions` is a mere hack. It's effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how a value is substituted in a query. You'd have to parse a subset of SQL to actually know which object are permissions granted to for a user). After analyzing the existing modules I realized that in every case with a single exception[2] the UNIX system user is equal to the db user is equal to the db name and I don't see a compelling reason why people would change that in 99% of the cases. In fact, some modules would even break if you'd change that because the declarations of the system user & the db user are mixed up[3]. So I decided to go with something new which restricts the ways to use `ensure*` options rather than expanding those[4]. Effectively this means that * The DB user _must_ be equal to the DB name. * Permissions are granted via `ensureDBOwnerhip` for an attribute-set in `ensureUsers`. That way, the user is actually the owner and can perform `CREATE`. * For such a postgres user, a database must be declared in `ensureDatabases`. For anything else, a custom state management should be implemented. This can either be `initialScript`, doing it manual, outside of the module or by implementing proper state management for postgresql[5], but the current state of `ensure*` isn't even declarative, but a convergent tool which is what Nix actually claims to _not_ do. Regarding existing setups: there are effectively two options: * Leave everything as-is (assuming that system user == db user == db name): then the DB user will automatically become the DB owner and everything else stays the same. * Drop the `createDatabase = true;` declarations: nothing will change because a removal of `ensure*` statements is ignored, so it doesn't matter at all whether this option is kept after the first deploy (and later on you'd usually restore from backups anyways). The DB user isn't the owner of the DB then, but for an existing setup this is irrelevant because CREATE on the public schema isn't revoked from existing users (only not granted for new users). [1] not really declarative though because removals of these statements are simply ignored for instance: https://github.com/NixOS/nixpkgs/issues/206467 [2] `services.invidious`: I removed the `ensure*` part temporarily because it IMHO falls into the category "manage the state on your own" (see the commit message). See also https://github.com/NixOS/nixpkgs/pull/265857 [3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";` [4] As opposed to other changes that are considered a potential fix, but also add more things like collation for DBs or passwords that are _never_ touched again when changing those. [5] As suggested in e.g. https://github.com/NixOS/nixpkgs/issues/206467
2023-11-08 12:50:09 +01:00
''
PSQL="psql --port=${builtins.toString cfg.settings.port}"
while ! $PSQL -d postgres -c "" 2> /dev/null; do
if ! kill -0 "$MAINPID"; then exit 1; fi
sleep 0.1
done
if test -e "${cfg.dataDir}/.first_startup"; then
${optionalString (cfg.initialScript != null) ''
$PSQL -f "${cfg.initialScript}" -d postgres
''}
rm -f "${cfg.dataDir}/.first_startup"
fi
''
+ optionalString (cfg.ensureDatabases != [ ]) ''
${concatMapStrings (database: ''
$PSQL -tAc "SELECT 1 FROM pg_database WHERE datname = '${database}'" | grep -q 1 || $PSQL -tAc 'CREATE DATABASE "${database}"'
'') cfg.ensureDatabases}
''
+ ''
${concatMapStrings (
user:
let
nixos/postgresql: drop ensurePermissions, fix ensureUsers for postgresql15 Closes #216989 First of all, a bit of context: in PostgreSQL, newly created users don't have the CREATE privilege on the public schema of a database even with `ALL PRIVILEGES` granted via `ensurePermissions` which is how most of the DB users are currently set up "declaratively"[1]. This means e.g. a freshly deployed Nextcloud service will break early because Nextcloud itself cannot CREATE any tables in the public schema anymore. The other issue here is that `ensurePermissions` is a mere hack. It's effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how a value is substituted in a query. You'd have to parse a subset of SQL to actually know which object are permissions granted to for a user). After analyzing the existing modules I realized that in every case with a single exception[2] the UNIX system user is equal to the db user is equal to the db name and I don't see a compelling reason why people would change that in 99% of the cases. In fact, some modules would even break if you'd change that because the declarations of the system user & the db user are mixed up[3]. So I decided to go with something new which restricts the ways to use `ensure*` options rather than expanding those[4]. Effectively this means that * The DB user _must_ be equal to the DB name. * Permissions are granted via `ensureDBOwnerhip` for an attribute-set in `ensureUsers`. That way, the user is actually the owner and can perform `CREATE`. * For such a postgres user, a database must be declared in `ensureDatabases`. For anything else, a custom state management should be implemented. This can either be `initialScript`, doing it manual, outside of the module or by implementing proper state management for postgresql[5], but the current state of `ensure*` isn't even declarative, but a convergent tool which is what Nix actually claims to _not_ do. Regarding existing setups: there are effectively two options: * Leave everything as-is (assuming that system user == db user == db name): then the DB user will automatically become the DB owner and everything else stays the same. * Drop the `createDatabase = true;` declarations: nothing will change because a removal of `ensure*` statements is ignored, so it doesn't matter at all whether this option is kept after the first deploy (and later on you'd usually restore from backups anyways). The DB user isn't the owner of the DB then, but for an existing setup this is irrelevant because CREATE on the public schema isn't revoked from existing users (only not granted for new users). [1] not really declarative though because removals of these statements are simply ignored for instance: https://github.com/NixOS/nixpkgs/issues/206467 [2] `services.invidious`: I removed the `ensure*` part temporarily because it IMHO falls into the category "manage the state on your own" (see the commit message). See also https://github.com/NixOS/nixpkgs/pull/265857 [3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";` [4] As opposed to other changes that are considered a potential fix, but also add more things like collation for DBs or passwords that are _never_ touched again when changing those. [5] As suggested in e.g. https://github.com/NixOS/nixpkgs/issues/206467
2023-11-08 12:50:09 +01:00
dbOwnershipStmt = optionalString user.ensureDBOwnership ''$PSQL -tAc 'ALTER DATABASE "${user.name}" OWNER TO "${user.name}";' '';
filteredClauses = filterAttrs (name: value: value != null) user.ensureClauses;
clauseSqlStatements = attrValues (mapAttrs (n: v: if v then n else "no${n}") filteredClauses);
userClauses = ''$PSQL -tAc 'ALTER ROLE "${user.name}" ${concatStringsSep " " clauseSqlStatements}' '';
in
''
$PSQL -tAc "SELECT 1 FROM pg_roles WHERE rolname='${user.name}'" | grep -q 1 || $PSQL -tAc 'CREATE USER "${user.name}"'
${userClauses}
nixos/postgresql: drop ensurePermissions, fix ensureUsers for postgresql15 Closes #216989 First of all, a bit of context: in PostgreSQL, newly created users don't have the CREATE privilege on the public schema of a database even with `ALL PRIVILEGES` granted via `ensurePermissions` which is how most of the DB users are currently set up "declaratively"[1]. This means e.g. a freshly deployed Nextcloud service will break early because Nextcloud itself cannot CREATE any tables in the public schema anymore. The other issue here is that `ensurePermissions` is a mere hack. It's effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how a value is substituted in a query. You'd have to parse a subset of SQL to actually know which object are permissions granted to for a user). After analyzing the existing modules I realized that in every case with a single exception[2] the UNIX system user is equal to the db user is equal to the db name and I don't see a compelling reason why people would change that in 99% of the cases. In fact, some modules would even break if you'd change that because the declarations of the system user & the db user are mixed up[3]. So I decided to go with something new which restricts the ways to use `ensure*` options rather than expanding those[4]. Effectively this means that * The DB user _must_ be equal to the DB name. * Permissions are granted via `ensureDBOwnerhip` for an attribute-set in `ensureUsers`. That way, the user is actually the owner and can perform `CREATE`. * For such a postgres user, a database must be declared in `ensureDatabases`. For anything else, a custom state management should be implemented. This can either be `initialScript`, doing it manual, outside of the module or by implementing proper state management for postgresql[5], but the current state of `ensure*` isn't even declarative, but a convergent tool which is what Nix actually claims to _not_ do. Regarding existing setups: there are effectively two options: * Leave everything as-is (assuming that system user == db user == db name): then the DB user will automatically become the DB owner and everything else stays the same. * Drop the `createDatabase = true;` declarations: nothing will change because a removal of `ensure*` statements is ignored, so it doesn't matter at all whether this option is kept after the first deploy (and later on you'd usually restore from backups anyways). The DB user isn't the owner of the DB then, but for an existing setup this is irrelevant because CREATE on the public schema isn't revoked from existing users (only not granted for new users). [1] not really declarative though because removals of these statements are simply ignored for instance: https://github.com/NixOS/nixpkgs/issues/206467 [2] `services.invidious`: I removed the `ensure*` part temporarily because it IMHO falls into the category "manage the state on your own" (see the commit message). See also https://github.com/NixOS/nixpkgs/pull/265857 [3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";` [4] As opposed to other changes that are considered a potential fix, but also add more things like collation for DBs or passwords that are _never_ touched again when changing those. [5] As suggested in e.g. https://github.com/NixOS/nixpkgs/issues/206467
2023-11-08 12:50:09 +01:00
${dbOwnershipStmt}
''
) cfg.ensureUsers}
'';
serviceConfig = mkMerge [
{
2016-02-09 03:07:23 +03:00
ExecReload = "${pkgs.coreutils}/bin/kill -HUP $MAINPID";
User = "postgres";
Group = "postgres";
RuntimeDirectory = "postgresql";
Type = if versionAtLeast cfg.package.version "9.6" then "notify" else "simple";
# Shut down Postgres using SIGINT ("Fast Shutdown mode"). See
# https://www.postgresql.org/docs/current/server-shutdown.html
KillSignal = "SIGINT";
KillMode = "mixed";
# Give Postgres a decent amount of time to clean up after
# receiving systemd's SIGINT.
TimeoutSec = 120;
ExecStart = "${cfg.finalPackage}/bin/postgres";
# Hardening
CapabilityBoundingSet = [ "" ];
DevicePolicy = "closed";
PrivateTmp = true;
ProtectHome = true;
ProtectSystem = "strict";
MemoryDenyWriteExecute = lib.mkDefault (
cfg.settings.jit == "off" && (!any extensionInstalled [ "plv8" ])
);
NoNewPrivileges = true;
LockPersonality = true;
PrivateDevices = true;
PrivateMounts = true;
ProcSubset = "pid";
ProtectClock = true;
ProtectControlGroups = true;
ProtectHostname = true;
ProtectKernelLogs = true;
ProtectKernelModules = true;
ProtectKernelTunables = true;
ProtectProc = "invisible";
RemoveIPC = true;
RestrictAddressFamilies = [
"AF_INET"
"AF_INET6"
"AF_NETLINK" # used for network interface enumeration
"AF_UNIX"
];
RestrictNamespaces = true;
RestrictRealtime = true;
RestrictSUIDSGID = true;
SystemCallArchitectures = "native";
nixos/postgresql: allow customisations of SystemCallFilter 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.
2025-03-02 11:06:49 +01:00
SystemCallFilter = pipe cfg.systemCallFilter [
(mapAttrsToList (name: v: v // { inherit name; }))
(filter (getAttr "enable"))
sortProperties
(map (getAttr "name"))
];
UMask = if groupAccessAvailable then "0027" else "0077";
}
(mkIf (cfg.dataDir != "/var/lib/postgresql/${cfg.package.psqlSchema}") {
# The user provides their own data directory
ReadWritePaths = [ cfg.dataDir ];
})
(mkIf (cfg.dataDir == "/var/lib/postgresql/${cfg.package.psqlSchema}") {
# Provision the default data directory
StateDirectory = "postgresql postgresql/${cfg.package.psqlSchema}";
StateDirectoryMode = if groupAccessAvailable then "0750" else "0700";
})
];
unitConfig.RequiresMountsFor = "${cfg.dataDir}";
};
};
meta.doc = ./postgresql.md;
meta.maintainers = with lib.maintainers; [
thoughtpolice
danbst
];
}