I recently changed my user’s umask from 022 to 077, thanks to #479119. However, this means that also processes that I run via sudo use 077 as the umask now. Is this problematic when running nixos-rebuild via sudo?
Hi, author of the PR here. I’ve had my user umask set to 077 since before opening that PR, and have not encountered any issues with nixos-rebuild (nor any other Nix components/commands) so far.
AFAIK nix explicitly sets the permissions on store paths to 444/555 (for executable files), so your umask shouldn’t have any effect on them.
1 Like
Right, derivations get their permissions normalized, probably not least for the sake of purity. I was just wondering whether files outside of the Nix store might get wrong permissions. In particular, I don’t know what exactly the activation script is doing. In my opinion, nixos-rebuild and other Nix and NixOS tools should be independent of the umask setting, but I’d be interested to know whether they actually are. 
By the way, thanks a lot for the above-mentioned contribution, @aionescu: it’s a real pleasure that finally all my user’s files have permissions rw------- or rwx------ and this will stay this way (I confirmed with the help of /proc that really all running user processes had 077 as their umask after the fix).
1 Like
While I haven’t looked at the code so I can’t say for certain, AFAIK all nixos-rebuild does (besides running the activation script of course) is update the symlinks for “profiles”/generations, and the activation script only creates symlinks outside the store (in /etc). The only times it creates files outside the store is when you explicitly configure their permissions using environment.etc, so they shouldn’t be affected by your umask.
If there are any issues caused by changing the umask (though I doubt it), I would expect to see most reports coming in after @Majiir ‘s subsequent PR (#479143) gets merged.
Thanks for the kudos, I’m glad my contribution has helped you!
1 Like
Does it sometimes create directories outside the store? (Well, directories are also files according to Unix terminology, but it’s not universally shared terminology, and therefore I better ask. )
The script is executed with systemd-run and these args.
I’m not completely, though pretty certain, and I can’t find any documentation explicitly confirming this, but since systemd-run goes through RPC with PID 1 there should be no inheritance involved, so your user’s umask shouldn’t affect anything.
I’m too lazy to check if the (deprecated) non-ng nixos-rebuild uses systemd-run too, but the source is pretty easy to find if you want to check yourself.
The activation scripts themselves don’t seem to touch the umask anywhere, so systemd-run is the environment sanity barrier afaict. Reasonable choice, honestly.
For the record, some directories and files are created by the activation scripts; at the very least the boot entries in /boot, but there are probably other things too.
Pretty much everywhere else where symlinks aren’t sufficient, systemd-tmpfiles is used (which controls file modes explicitly), but the activation scripts can in theory do anything, so there aren’t exactly guards against someone doing something stupid.
Your activation script runs on every boot, by the way, so mode issues could have pretty funky results.
1 Like