Bug 1777718

On my recently installed RHEL8 without any significant modifications I see the following:

[root@localhost ~]# ssh tester@localhost umask
tester@localhost's password: 
0002
[root@localhost ~]# ssh root@localhost umask
root@localhost's password: 
0022
[root@localhost ~]# rpm -q openssh
openssh-8.0p1-3.el8.x86_64
[root@localhost ~]# grep root /etc/passwd
root:x:0:0:root:/root:/bin/bash
[root@localhost ~]# grep tester /etc/passwd
tester:x:1000:1000:Tester:/home/tester:/bin/bash

This sounds like there is something in the way changing this for you, but it does not sound like default nor anything inside of openssh. Can you try with fresh RHEL8 without any modifications, whether you can reproduce my observations? Assuming you are using bash and password authentication. If you use something else, please clarify.

Do you have a '.bashrc' file for your user? 

I think local users gets one by default, which includes:

# Source global definitions
if [ -f /etc/bashrc ]; then
	. /etc/bashrc
fi


But our users are from AD with NFS mounted home directory, so they have no .bashrc since they've had no need for it. 

So please test again without sourcing /etc/bashrc.

You are right. Without the default I can see the same behavior as you. But this umask is not set by sshd, but (most probably) in the pam stack as /etc/pam.d/postlogin contains the pam_umask module and it pulls this value from /etc/login.defs to have for all logins systematic umasks. This was not in RHEL7 so it did not have to be completely systematic in the past.

I will reassign this to authselect, which generates these pam stacks for you and they will hopefully have better idea behind the reasoning why this was introduced. But I think the correct way is to change this system-wide in login.defs. If you want different values for sshd, you can modify sshd pam stack to overwrite the umask to something else.

[root@localhost ~]# rm /home/tester/.bashrc
rm: remove regular file '/home/tester/.bashrc'? y
[root@localhost ~]# ssh tester@localhost umask
tester@localhost's password: 
0077
[root@localhost ~]# grep umask /etc/pam.d/postlogin
#session optional                   pam_umask.so silent
[root@localhost ~]# ssh tester@localhost umask
tester@localhost's password: 
0022

ah, thank you - its in the postlogin, then I know what sets it. But yes, would also be interesting to know if there is a reasoning behind this.

The use of pam_umask was added for consistency among various login methods.

And the value of UMASK 077 in login.defs was there since ages. However it is true that this value is not convenient and expected. We could change the value to 022 but that would require shadow-utils update.

BTW the value of UMASK in login.defs does not have any effect on RHEL-7, so there should not be any problem with changing it to 022 on RHEL-8. It really affects only user logins.

Actually I have to take it back - sorry for the confusion - the value has to stay at 077 because this value is used when creating home directories for new users and we want that value to be applied there.

So the only solution is to change authselect to add umask=022 on pam_umask cmdline. Whether it has any unwanted consequences I am not sure.

Here is the bugzilla that requested pam_umask: https://bugzilla.redhat.com/show_bug.cgi?id=1558599

Why is 022 better default then 077?

Because 077 is kind-of unexpected umask value as it makes all the files you create unreadable to others. That is usually not what you want to do. On the other hand having the user's home directory with permissions that disallow looking into it to others is actually desirable. It was kind-of unfortunate to re-use the UMASK login.defs value for these two fairly separate purposes. I am sorry for not realizing this when I was consulted about the change that added pam_umask to the default configuration.

In theory we could do something with it else than adding umask=022 to the pam_umask cmdline however it would require simultaneous changes in both shadow-utils and pam. We would have to add a new LOGIN_UMASK value to login.defs and pam_umask could start using it instead of UMASK if it is set. And we could modify the login.defs in shadow-utils to add LOGIN_UMASK with value of 022.

Or perhaps pam umask could start using different configuration file? Say /etc/security/pam_umask.conf? This way only one component needs to be modified and it does not need to be hardcoded in pam.

This has a disadvantage that we could not introduce a setting in /etc/security/pam_umask.conf without risk of breaking existing customers that depend on some non-default umask value set in login.defs.

Setting pam_umask=022 will break those customers as well (or do I miss something?) and worse, to change that they would have to create custom authselect profile. Configuration option can be set to possible non-default value during install scriptlet.

Yes, I was not comparing it to the pam_umask command line setting but to the LOGIN_UMASK in login.defs.

I'm moving this to pam component as I think pam_umask should read custom configuration option given the fact that UMASK from login.defs serves completely different purpose.

The final solution should be to set the UMASK to 022 in login.defs and add support for HOME_MODE and set it to 077. I am reassigning the bug to shadow-utils as that is the component that contains login.defs.

And to make it clear - with the change from comment 17 no changes in pam or authselect packages should be needed.

As Tomas has already pointed the fix will include the change in login.defs of UMASK to 022 and HOME_MODE to 0700, as it isn't a masked value. This issue is similar to https://bugzilla.redhat.com/show_bug.cgi?id=1807957 in Fedora.

(In reply to Iker Pedrosa from comment #19)
> As Tomas has already pointed the fix will include the change in login.defs
> of UMASK to 022 and HOME_MODE to 0700, as it isn't a masked value. This
> issue is similar to https://bugzilla.redhat.com/show_bug.cgi?id=1807957 in
> Fedora.

Yes, I am sorry for confusing things with mentioning HOME_MODE as if it was an umask value.

* master
    a847899b521b0df0665e442845bcff23407d9ea0 - add new HOME_MODE login.defs(5) option

*** Bug 1833664 has been marked as a duplicate of this bug. ***

checked with:

[root@ci-vm-10-0-105-73 ~]# rpm -qa shadow-utils openssh
openssh-8.0p1-5.el8.x86_64
shadow-utils-4.6-10.el8.x86_64

Verification steps:
1) Add local user and change password
[root@ci-vm-10-0-105-73 ~]# useradd madhuri
[root@ci-vm-10-0-105-73 ~]# passwd madhuri
Changing password for user madhuri.
New password: 
BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word
Retype new password: 
passwd: all authentication tokens updated successfully.

2) remove rm  /home/madhuri/.bashrc 
[root@ci-vm-10-0-105-73 ~]# rm  /home/madhuri/.bashrc 
rm: remove regular file '/home/madhuri/.bashrc'? yes

3) Check authentication and mask

[root@ci-vm-10-0-105-73 ~]# ssh madhuri@localhost umask
madhuri@localhost's password: 
0077

[root@ci-vm-10-0-105-73 ~]# cat  /etc/login.defs | grep UMASK
UMASK           077

Getting 0077, the expected value is 0022,
Thus marking this FailedQA.

Yes, apparently the login.defs file as shipped in the package was not changed at all, only the HOME_MODE support was added to the utilities.

Verified with:
[root@ci-vm-10-0-96-221 ~]# rpm -qa shadow-utils openssh
openssh-8.0p1-5.el8.x86_64
shadow-utils-4.6-11.el8.x86_64

Verification steps:

1) Add local user and change the password of user
[root@ci-vm-10-0-96-221 ~]# useradd madhuri
[root@ci-vm-10-0-96-221 ~]# passwd madhuri
Changing password for user madhuri.
New password: 
BAD PASSWORD: The password is shorter than 8 characters
Retype new password: 
passwd: all authentication tokens updated successfully.

2) Check the home directory folder permission

[root@ci-vm-10-0-96-221 ~]# ls -l /home
total 0
drwx------. 4 cloud-user cloud-user 90 Aug 10 03:07 cloud-user
drwx------. 2 madhuri    madhuri    62 Aug 10 03:23 madhuri

Home directory permission is 700.

3) Remove  /home/madhuri/.bashrc 

[root@ci-vm-10-0-96-221 ~]# rm  /home/madhuri/.bashrc 
rm: remove regular file '/home/madhuri/.bashrc'? yes

4) Check authentication and mask
[root@ci-vm-10-0-96-221 ~]# ssh madhuri@localhost umask
madhuri@localhost's password: 
0022

5) 
[root@ci-vm-10-0-96-221 ~]#  cat  /etc/login.defs | grep UMASK
# UMASK is also used by useradd(8) and newusers(8) to set the mode for new
UMASK		022
# If HOME_MODE is not set, the value of UMASK is used to create the mode.


From above steps marking this bug verified.

This change broke default permissions to home directories created with pam_oddjob_mkhomedir.so because UMASK value became less secure.

See https://bugzilla.redhat.com/show_bug.cgi?id=1886362

Please note that nobody informed oddjob that it needs to start reading HOME_MODE variable instead of UMASK from /etc/login.defs.

The main reason is that nobody expected pam_oddjob_mkhomedir to silently ignore its module options and to read /etc/login.defs instead.

This is also opportunity to add a testcase of pam_oddjob_mkhomedir to shadow-utils and pam testplans.

Man page of pam_oddjob_mkhomedir.so explicitly tells that it doesn't support *any* PAM options. It never did, for the lifetime of this project. ;)

Please add a test case. With https://pagure.io/oddjob/pull-request/12 merged, oddjob should support HOME_MODE and UMASK.

I would also argue that a change like this (semantic change of UMASK usage and introduction of HOME_MODE) is a release change. At least in Fedora, this should have been a system-wide change that would need to be announced in advance.

I take a note to write a system-wide change when something important is changed around login.defs file

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (shadow-utils bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4467