Arch Linux

Did a quick test and it works fine here: /etc/login.defs' UMASK is now respected.

The key feature to make it work is the new /etc/login.defs' HOME_MODE option.

Related:
https://github.com/systemd/systemd/issues/6077

Systemd has fixed this. I have tested this myself on my pc for sometime and it works.

There is some overlap with  FS#69933  perhaps the changes should be reviewed together by the same developers?

Currently umask is set 077 in /etc/login.defs, that will be replaced by 022 for anything that has sourced /etc/profile.
Does anything apart from useradd and newusers use the 077 umask?
Why is HOME_MODE commented in upstream's /etc/login.defs?

HOME_MODE defaults to UMASK if unset, so unless we want it different there it can be commented.

@marcthe12 what values are you testing with for HOME_MODE and UMASK?
I thought the proposal was:
UMASK 022 which is what upstream uses
HOME_MODE 0700 which is what upstream uses although it has it commented out.
If UMASK is 022 and HOME_MODE is not set so 022 is used, would that create home directories with 0755 permissions?

Edit:
logins that do not use pam such as telnet from inetutils would no longer have umask set?

How do the pri (priority) and ulimit (fsize) which may set by pam_umask from a users gecos field interact with the values set by pam_limits?
Edit2:
Attached diffs of what I understand the proposed changes to be. There is a separate version of the patch for shadow in  FS#69933  that applies on top of those changes.

Related KDE bug report:
https://bugs.kde.org/show_bug.cgi?id=445801

> If UMASK is 022 and HOME_MODE is not set so 022 is used, would that create home directories with 0755 permissions?

As we've seen recently [1], it is indeed the case, that new home directories are created with 0755 permissions.

FWIW, I'd be up for changing this in an update to shadow and pambase, but we'd also need to coordinate this with the filesystem package to remove the umask call from /etc/profile.

[1] https://bugs.archlinux.org/task/69933#comment212052

Updated diffs. Only none context change was moving pam_umask.so above pam_systemd.so so if a systemd-homed user record includes a umask it will not be overwritten.

Now that  FS#69933  is closed, can we implement this?

This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.

Still relevant. Implementation is straightforward (see @loqs patches), but it will probably need a front page note for folks with modified /etc/login.defs, otherwise UMASK 077 -> UMASK 022 and #HOME_MODE -> HOME_MODE 0700 changes will not apply. Update: and modified /etc/pam.d/system-login too...

I have applied to changes to pambase in https://gitlab.archlinux.org/archlinux/packaging/packages/pambase/-/commit/0c62da22f37ca4435d5651dd68c987d0ad02d351

@seblu: The changes to /etc/profile in filesystem are done in https://gitlab.archlinux.org/archlinux/packaging/packages/filesystem/-/commit/4a36801a4d7eb169298037b914887f0aeb14e1ad

**NOTE**: This **requires** us to release filesystem, pambase and shadow **together** to not mess this up! I'll try to get to that this week!

There is now filesystem 2023.09.18-1, pambase 20230918-1 and shadow 4.14.0-1 in [core-testing].

Please give it a thorough test and report back with any problems!

With modified /etc/login.defs:

(11/11) atualizando shadow [...]
atenção: /etc/login.defs instalado como /etc/login.defs.pacnew

After login:

# umask
0077

from the old UMASK 077, used to satisfy useradd before HOME_MODE. A message "umask configuration has changed. Check for /etc/login.defs.pacnew and /etc/pam.d/system-login.pacnew and merge changes if necessary" or so would help IMHO.

Besides that, works fine!