Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#66068 - [filesystem][pambase][shadow] Use

Attached to Project: Arch Linux
Opened by Marcos Mello (marcosfrm) - Wednesday, 01 April 2020, 19:56 GMT
Last edited by David Runge (dvzrv) - Friday, 22 September 2023, 20:33 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Sébastien Luttringer (seblu)
David Runge (dvzrv)
Levente Polyak (anthraxx)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Would this approach benefit Arch?

If I get things correctly:

- Add "session optional" to PAM stack (system-login)
- Synchronize /etc/login.defs with upstream shadow: set UMASK to 022 and new option (since 4.8.1) HOME_MODE to 0700.
- Drop umask call from /etc/profile (filesystem package)

This way umask configuration is centralized in /etc/login.defs.
This task depends upon

Closed by  David Runge (dvzrv)
Friday, 22 September 2023, 20:33 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with shadow 4.14.0-3, filesystem 2023.09.18, pambase 20230918
Comment by Marcos Mello (marcosfrm) - Thursday, 02 April 2020, 11:41 GMT
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.
Comment by Marcos Mello (marcosfrm) - Sunday, 05 April 2020, 09:57 GMT Comment by marc boocha (marcthe12) - Sunday, 06 June 2021, 03:15 GMT
Systemd has fixed this. I have tested this myself on my pc for sometime and it works.
Comment by loqs (loqs) - Sunday, 06 June 2021, 05:18 GMT
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?
Comment by marc boocha (marcthe12) - Sunday, 06 June 2021, 05:38 GMT
HOME_MODE defaults to UMASK if unset, so unless we want it different there it can be commented.
Comment by loqs (loqs) - Sunday, 06 June 2021, 06:00 GMT
@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?

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?
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.
Comment by Antonio Rojas (arojas) - Tuesday, 28 December 2021, 11:47 GMT Comment by David Runge (dvzrv) - Thursday, 20 October 2022, 10:16 GMT
> 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.

Comment by loqs (loqs) - Monday, 24 October 2022, 16:28 GMT
Updated diffs. Only none context change was moving above so if a systemd-homed user record includes a umask it will not be overwritten.
Comment by Marcos Mello (marcosfrm) - Sunday, 04 June 2023, 18:20 GMT
Now that  FS#69933  is closed, can we implement this?
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
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.
Comment by Marcos Mello (marcosfrm) - Wednesday, 23 August 2023, 19:06 GMT
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...
Comment by David Runge (dvzrv) - Monday, 18 September 2023, 10:47 GMT
I have applied to changes to pambase in

@seblu: The changes to /etc/profile in filesystem are done in

**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!
Comment by David Runge (dvzrv) - Monday, 18 September 2023, 13:45 GMT
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!
Comment by Marcos Mello (marcosfrm) - Monday, 18 September 2023, 18:03 GMT
With modified /etc/login.defs:

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

After login:

# umask

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!