You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As you can tell my directory /run/user/1000/secrets.d/2 is readable by other users. However, I do not necessarily want to let other users know what kind of passwords I store even if they can't read them. To at least have the option of privacy I think the easiest fix would be to XOR all permissions of the keys and set it as the permission of the generations directory.
The text was updated successfully, but these errors were encountered:
Mikilio
changed the title
Permissions of secrets.d
Permissions of secrets.d generations
Jul 17, 2023
It is true /run/user/1000 has 700 and its files can not be accessed directly!
The vulnerability comes from something I was in control of myself. Basically because of #287 I have set the paths to a directory in my somewhere in my home directory and that was to one that had loose permissions. Any user could see which keys I have, because the symlinks have the same name as the actual file.
Now the symlinks weren't created by myself but by the newly introduced option in sops-nix , so I don't know if there should be a check for this kind of unsecurity or if secret files should be hashed or if this should be blamed on the user.
I am using the home-manager module.
I've censored some
ls
commands to illustrate the issue:As you can tell my directory
/run/user/1000/secrets.d/2
is readable by other users. However, I do not necessarily want to let other users know what kind of passwords I store even if they can't read them. To at least have the option of privacy I think the easiest fix would be to XOR all permissions of the keys and set it as the permission of the generations directory.The text was updated successfully, but these errors were encountered: