Is it possible sops-nix mkdirs with wrong permissions?

[colemickens]

sudo rm -rf ~/.config/gh
sudo /run/current-system/bin/switch-to-configuration activate

results in:

Aug 12 18:19:52 radxazero1 hm-activate-cole[4026]: Activating installPackages
Aug 12 18:19:52 radxazero1 hm-activate-cole[4026]: Activating linkGeneration
Aug 12 18:19:52 radxazero1 hm-activate-cole[4026]: Cleaning up orphan links from /home/cole
Aug 12 18:19:52 radxazero1 hm-activate-cole[4026]: No change so reusing latest profile generation 4
Aug 12 18:19:52 radxazero1 hm-activate-cole[4026]: Creating home file links in /home/cole
Aug 12 18:19:53 radxazero1 hm-activate-cole[4235]: ln: failed to create symbolic link '/home/cole/.config/gh/config.yml': Permission denied

And sure enough:

cole@radxazero1 ~
❯ ls -al ~/.config/gh       
total 8
drwxr-xr-x  2 root root 4096 Aug 12 18:19 .
drwx------ 22 cole cole 4096 Aug 12 18:19 ..
lrwxrwxrwx  1 cole cole   25 Aug 12 18:19 hosts.yml -> /run/secrets/gh-hosts.yml

But my sops config for that file:

{ pkgs, config, ... }:

{
  config = {
    sops.secrets."gh-hosts.yml" = {
      owner = "cole";
      group = "cole";
      path = "/home/cole/.config/gh/hosts.yml";
    };
    home-manager.users.cole = { pkgs, ... }: {
      programs.gh = {
        enable = true;
      };
    };
  };

Obviously I can fix this one-off, but what's the right better solution?

[bertbesser]

I was pointed here from #391 . I worked around your issue using a system activation script that fixes the folder permissions.

[Mic92]

The problem is that it's not clear what the right behavior is in that case. Just because owner for the secret is the current user doesn't mean this is the right owner for its parent directory. Just imagine we have /var/lib/some-secret. It would be wrong to create /var/lib with the same owner as some-secret.

[superherointj]

I just encountered this issue. A root directory was created in my user home to satisfy the creation of a user file. So, only the directory created is owned by root and secret file is owned by the specified user.

Wouldn't be enough to just use same user for mkdir?

If else, what about having an extra option to 'permit' this behavior? As it could avoid the need of adding an ad-hoc activation script and be cleaner.

[Mic92]

Is it not better to offload creating of parent directories to systemd-tmpfiles?

[superherointj]

Thanks. Sorry about the flawed implementation.

Behavior wise: Do you think it is doable to create the directory but owned by the specified user without extra steps being necessary?