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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Professor" == Professor Jeebs <jeebs@tuta.io> 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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-04-08 14:13 -0600, Sam Hartman wrote:

"Professor" == Professor Jeebs <jeebs@tuta.io> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

control: clone -1 -2
control: retitle -2 Document pam_umask change in release notes

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hey.

Also with respect to having this documented in the release note, you
may want to have a look at my comment:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065806#47

I.e. I think it might be usefull to not just indicate that/how people
may use "nousergroups" again, but also to refer to alternatives (like
setting a per-user default UMASK via GECOS) by referring to the
pam_umask(8) manpage.


Cheers,
Chris.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)