/run/secrets.d/ generations not accessible to "keys" group

[stephane-at-m]

The documentation recommends to add users that need to access secrets to also belong to the keys group. I believe the reason for this is that the parent folders to the actual secret are owned by root:keys.

In my case it seems that /run/secrets.d is indeed accessible to root user and the keys group, but any generations inside the secrets.d folder are chmod'ed only to allow root owner access, not keys group:

ls -la /run/secrets.d
total 4
drwxr-x--x  3 root keys   0 Oct  1 18:44 .
drwxr-xr-x 27 root root 720 Oct  1 18:44 ..
drwx------  2 root keys   0 Oct  1 18:44 31
-rw-------  1 root root 318 Oct  1 18:44 age-keys.txt

when I would actually expect

drwxr-x---  2 root keys   0 Oct  1 18:44 31

I cannot fix this permanently, only one-off but any further rebuild would reset permissions for the next generation

[Mic92]

Interesting. For me the permissions look differently:

 sudo ls -la /run/secrets.d
total 4
drwxr-x--x  3 root keys   0 Sep 30 13:01 .
drwxr-xr-x 31 root root 960 Oct  3 08:50 ..
drwxr-x--x  2 root keys   0 Sep 30 13:01 6
-rw-------  1 root root 128 Sep 30 13:01 age-keys.txt

You actually no longer need the keys group for the most part. You can give users/groups read-access to a secret without them being part in the secret group. They just cannot list the directory otherwise.

[Mic92]

Updated documentation: 9de50ec

[stephane-at-m]

Indeed. The permissions of the folder become similar to yours after a system reboot.
Looks like sops-nix needs a system reboot to work effectively with folder permissions.

[stephane-at-m]

@Mic92, I finally understood what happens here. This is actually not resolved by a server restart.

My configuration is using the users.ldap module, and as soon as I set the users.ldap.bind.passwordFile, an activation script gets created that sets the umask to 0077. The sops-nix activation script being called after the one from users.ldap, it seems to be affected by that umask setting and therefore does not allow any permissions to group or other.

Is this an issue with sops-nix which should reset or ignore any umask being set upfront? or is this an issue with the users.ldap module which should reset the umask to whatever it was set to at the end of the activation script (for example by saving it upfront to old_umask=$(umask)?

[bjornfor]

an activation script gets created that sets the umask to 0077.

IMHO the bug is there in users.ldap; that snippet should run in a subshell to not leak umask to other activation snippets.