Bug#1065806: pam: recent upgrade changes previous default umask
control: clone -1 -2 control: retitle -2 Document pam_umask change in release notes
Bug#1065806: pam: recent upgrade changes previous default umask
On 2024-04-08 14:13 -0600, Sam Hartman wrote: >> "Professor" == Professor Jeebs writes: > > > Professor> I prefer the way it is handled per user. There is a related, > commented > Professor> out, option in /etc/skel/.profile, which lands in new user > directories, > Professor> which I have never touched the umask part until now. I > uncommented the > Professor> line to set the users' default umask settings to 022 and > updated users > Professor> already on the system. > > > Just confirming. You could have modified /etc/login.defs if you chose > and gotten a similar affect, right? I think the file to edit is actually /etc/pam.d/common-session, adding the "nousergroups" option in the line with pam_umask.so. That is what I did after reading the pam_umask(8) manpage. Cheers, Sven
Bug#1065806: pam: recent upgrade changes previous default umask
> "Professor" == Professor Jeebs writes: Professor> I prefer the way it is handled per user. There is a related, commented Professor> out, option in /etc/skel/.profile, which lands in new user directories, Professor> which I have never touched the umask part until now. I uncommented the Professor> line to set the users' default umask settings to 022 and updated users Professor> already on the system. Just confirming. You could have modified /etc/login.defs if you chose and gotten a similar affect, right?
Bug#1065806: pam: recent upgrade changes previous default umask
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
Bug#1065806: pam: recent upgrade changes previous default umask
The change of behaviour can have an unexpected and quite nasty side-effect, by applying a misconfiguration that was ignored until this update. A setting of "UMASK 077" in /etc/login.defs was ignored before this update, and is now applied (as it should) leading to unreadable files if the user is not expecting it. In my case this was a misconfiguration, as I thought it was a setting applied only to the $HOME directory itself (I should have used "HOME_MODE 0700" instead). But since it had no effect until the recent update, I got taken by surprise with files generated with rw-rw permissions when I was expecting the regular rw-r--r--. I am not bumping the severity of this bug report because the new behaviour is the correct one, but it should be kept in mind that other people might get unexpected effects from this update.
Bug#1065806: pam: recent upgrade changes previous default umask
Source: pam Version: 1.5.3-6 Severity: normal Hey. Somwhere in between 1.5.2-9.1+b1 and 1.5.3-6 the default umask for non-root users has changed from 0022 to 0002. Interestingly, root doesn't seem to be affected. Intially I suspected b01196659c785b04abc387d324fae61e2ec3b1aa, but at least when re-commenting the: > session optional pam_umask.so in both files again, it still stays at 0002. I don't so much mind the change itself, but shouldn't such a big change go at least into NEWS.Debian and probably also he release notes? Cheers, CHris. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.7.7-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
