Good Day, I also noticed this change recently, and found it jarring, albeit mostly cosmetic. The notes in /etc/login.defs do imply that it is up to administrators, who we know have differing opinions on all matters of topics. For example, I would like to keep the old USERGROUPS_ENAB set to "yes", *and* to have a default umask of 022 (for reasons; even if that does not make a lick of sense). Also, I often do have multiple users on my systems who belong to a single group (something like "users").
I remember posting on systemd @ github about how they were choosing to handle, or not handle values in /etc/login.defs--or, maybe something else semi-related--at a time in ancient history. The details, I do not recall. But, I do not blame, nor believe, the systemd project has anything to do with this particular change. Please correct me, if I am wrong! And, maybe I can even be convinced that one handling of umasks is better than... Here is how I am handling it now... In the default .bashrc for *root*, ever since I can remember, I have had a configuration line commented out, which allows setting the umask value to 022 for root. This is how it still behaves by default anyway, as stated above. However, I am thinking to go ahead and... I prefer the way it is handled per user. There is a related, commented out, option in /etc/skel/.profile, which lands in new user directories, which I have never touched the umask part until now. I uncommented the line to set the users' default umask settings to 022 and updated users already on the system. At your own risk, if you follow along further :) It was fun to see and reset the permissions on files since the change, with: ~$ find . -type f -perm 664 and, upon confirming these are (mostly) the new files that I would have preferred to have different permissions (as before), reset them all with: ~$ find . -type f -perm 664 -execdir chmod 644 '{}' '+' (Note: wireplumber keeps some state files in my home folders at 664, which I guess is just the way they want it. Some other programs may prefer different permissions and reset them, also. We will see!) So far, I have not inspected, nor determined, whether directory permissions were affected in a way I might find jarring. Lastly, I already have .bash_profile and .xsessionrc doing little else than 'sourcing' .profile and setting a few variables where appropriate. I don't SSH into the box very often, so I am unsure if the umask holds in various other situations. Just my two cents, Professor Jeebs