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
