diff options
| author | Florian Klink <flokli@flokli.de> | 2020-02-05 01:53:26 +0100 |
|---|---|---|
| committer | Florian Klink <flokli@flokli.de> | 2020-02-05 01:53:26 +0100 |
| commit | 3c74e48d9c8dbcede89a72ea18cd27def4b498a9 (patch) | |
| tree | 0b13332d98f4d42fbf5ed330a409c7f4e12fcbc3 /nixos | |
| parent | 2ec5c4adf9e7357f11270243a8a591e5243a2151 (diff) | |
nixos/filesystems: ensure keys gid on /run/keys mountpoint
boot.specialFileSystems is used to describe mount points to be set up in
stage 1 and 2.
We use it to create /run/keys already there, so sshd-in-initrd scenarios
can consume keys sent over through nixops send-keys.
However, it seems the kernel only supports the gid=… option for tmpfs,
not ramfs, causing /run/keys to be owned by the root group, not keys
group.
This was/is worked around in nixops by running a chown root:keys
/run/keys whenever pushing keys [1], and as machines had to have pushed keys
to be usable, this was pretty much always the case.
This is causing regressions in setups not provisioned via nixops, that
still use /run/keys for secrets (through cloud provider startup scripts
for example), as suddenly being an owner of the "keys" group isn't
enough to access the folder.
This PR removes the defunct gid=… option in the mount script called in
stage 1 and 2, and introduces a tmpfiles rule which takes care of fixing
up permissions as part of sysinit.target (very early in systemd bootup,
so before regular services are started).
In case of nixops deployments, this doesn't change anything.
nixops-based deployments receiving secrets from nixops send-keys in
initrd will simply have the permissions already set once tmpfiles is
started.
Fixes #42344
[1]: https://github.com/NixOS/nixops/blob/884d6c3994b227eb09c307e5d25d6885c9af8220/nixops/backends/__init__.py#L267-L269
Diffstat (limited to 'nixos')
| -rw-r--r-- | nixos/modules/tasks/filesystems.nix | 8 |
1 files changed, 6 insertions, 2 deletions
diff --git a/nixos/modules/tasks/filesystems.nix b/nixos/modules/tasks/filesystems.nix index 688c77cb22d1..965a1c9eb1a6 100644 --- a/nixos/modules/tasks/filesystems.nix +++ b/nixos/modules/tasks/filesystems.nix @@ -304,6 +304,10 @@ in in listToAttrs (map formatDevice (filter (fs: fs.autoFormat) fileSystems)); + systemd.tmpfiles.rules = [ + "Z /run/keys 0750 root ${toString config.ids.gids.keys}" + ]; + # Sync mount options with systemd's src/core/mount-setup.c: mount_table. boot.specialFileSystems = { "/proc" = { fsType = "proc"; options = [ "nosuid" "noexec" "nodev" ]; }; @@ -312,8 +316,8 @@ in "/dev/shm" = { fsType = "tmpfs"; options = [ "nosuid" "nodev" "strictatime" "mode=1777" "size=${config.boot.devShmSize}" ]; }; "/dev/pts" = { fsType = "devpts"; options = [ "nosuid" "noexec" "mode=620" "ptmxmode=0666" "gid=${toString config.ids.gids.tty}" ]; }; - # To hold secrets that shouldn't be written to disk (generally used for NixOps, harmless elsewhere) - "/run/keys" = { fsType = "ramfs"; options = [ "nosuid" "nodev" "mode=750" "gid=${toString config.ids.gids.keys}" ]; }; + # To hold secrets that shouldn't be written to disk + "/run/keys" = { fsType = "ramfs"; options = [ "nosuid" "nodev" "mode=750" ]; }; } // optionalAttrs (!config.boot.isContainer) { # systemd-nspawn populates /sys by itself, and remounting it causes all # kinds of weird issues (most noticeably, waiting for host disk device |