Bug 1773567

Summary: no support for UID_MIN in /etc/login.defs
Product: Red Hat Enterprise Linux 8 Reporter: Pavel Březina <pbrezina>
Component: authselectAssignee: Pavel Březina <pbrezina>
Status: CLOSED ERRATA QA Contact: Madhuri <mupadhye>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.0CC: edgar.hoch, extras-qa, jhrozek, mupadhye, pbrezina, terje.rosten, thalman, tmraz
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: sync-to-jira
Fixed In Version: authselect-1.2.1-1.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1745136 Environment:
Last Closed: 2020-11-04 01:51:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1745136    
Bug Blocks:    

Description Pavel Březina 2019-11-18 13:48:06 UTC
+++ This bug was initially created as a clone of Bug #1745136 +++

Description of problem:

Seems like this bug from authconfig is repeated in authselect:

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

Setting UID_MIN in /etc/login.defs dont propagate to /etc/pam.d/password-auth
and /etc/pam.d/system-auth after run of authselect.

Please add this feature.

--- Additional comment from Pavel Březina on 2019-09-16 08:06:52 UTC ---

Upstream ticket:
https://github.com/pbrezina/authselect/issues/182

--- Additional comment from Pavel Březina on 2019-10-02 12:50:52 UTC ---

Thinking about this, I do not think that authselect (or authconfig) is the correct place for this. Everytime /etc/login.defs is changed authselect would have to be called again in order to regenerate the pam stack with updated value.

Better solution would be to add a new feature to pam_succeed_if that would read the value from login.defs and use it. Something like:
pam_succeed_if.so uid >= UID_MIN

Tomas, what do you think? I could do the coding, but I want to know your opinion.

--- Additional comment from Tomas Mraz on 2019-10-02 13:22:59 UTC ---

It seems to me to be a little feature creep for pam_succeed_if.so. Maybe a better solution would be a new module - something like pam_usertype.so

It could have options like: "isregular" - if uid within UID_MIN and MAX, "issystem" - within SYS_UID_MIN SYS_UID_MAX. And "notregular" "notsystem" for inverted test. It could also support "use_uid" option similarly to pam_succeed_if.

--- Additional comment from Pavel Březina on 2019-10-03 09:06:57 UTC ---

Why not do this as part of pam_succeed_if?

--- Additional comment from Tomas Mraz on 2019-10-03 10:19:15 UTC ---

Because by adding reading of login.defs it would be overstretching its purpose.

--- Additional comment from Pavel Březina on 2019-10-03 10:35:58 UTC ---

From man page: "pam_succeed_if.so is designed to succeed or fail authentication based on characteristics of the account belonging to the user being authenticated"

It fits perfectly for "user isregular" and "user issystem" conditions. Besides the new module would share the whole code with pam_succeed_if because the logic and purpose is the same just the available conditions would be different.

--- Additional comment from Tomas Mraz on 2019-10-03 10:43:02 UTC ---

(In reply to Pavel Březina from comment #6)

> It fits perfectly for "user isregular" and "user issystem" conditions.
> Besides the new module would share the whole code with pam_succeed_if
> because the logic and purpose is the same just the available conditions
> would be different.

Not really. If these are just options, there would not be much code shared except for the usual PAM module boilerplate.

With my upstream hat on I really dislike adding this to pam_succeed_if.

--- Additional comment from Pavel Březina on 2019-10-03 11:00:32 UTC ---

Ok. Thank you for your opinion. I will write the new module.

Comment 1 Pavel Březina 2020-02-17 10:56:25 UTC
* `master`
  * 4cfb20423ca9a3e9b2b3de627b751e61fb0cf560 - profiles: switch uid checks to pam_usertype

Comment 6 Pavel Březina 2020-06-09 10:58:18 UTC
Steps to test:
- if it is an system account, i.e. uid in range <SYS_UID_MIN, SYS_UID_MAX> is is always authenticated through pam_unix (and not by sssd)
- the PAM configuration now reads these values from /etc/login.defs so any changes there should be immediately reflected

Comment 7 Madhuri 2020-08-11 12:33:06 UTC
Verified with
[root@ci-vm-10-0-105-117 ~]# rpm -qa authselect sssd
authselect-1.2.1-2.el8.x86_64
sssd-2.3.0-7.el8.x86_64

Verification steps:

1) Update the /etc/login.defs and change SYS_UID_MAX and SYS_GID_MAX value to 1999

[root@ci-vm-10-0-105-117 ~]# cat /etc/login.defs | grep 'SYS_'
SYS_UID_MIN               201
SYS_UID_MAX              1999
SYS_GID_MIN               201
SYS_GID_MAX              1999

2) Add the system user with uid 1200

[root@ci-vm-10-0-105-117 ~]# useradd --system test_bar -u 1200

[root@ci-vm-10-0-105-117 ~]# id test_bar
uid=1200(test_bar) gid=1200(test_bar) groups=1200(test_bar)

3) Add the ldap user with same uid

dn: uid=foo100,ou=People,dc=example,dc=test
objectClass: top
objectClass: posixAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
cn: foo100
uid: foo100
sn: foo100
loginShell: /bin/bash
homeDirectory: /home/foo100
uidNumber: 1200
gidNumber: 1200
mail: foo100
gecos: foo100 User
l: US
userPassword: Secret123

[root@ci-vm-10-0-105-117 ~]# getent passwd foo100@example1
foo100@example1:*:1200:1200:foo100 User::/bin/bash

4) Try to login the user with uid in the system range

[root@ci-vm-10-0-105-117 ~]# ssh -l foo100@example1 localhost
foo100@example1@localhost's password: 
Permission denied, please try again.
foo100@example1@localhost's password: 
Permission denied, please try again.
foo100@example1@localhost's password: 
foo100@example1@localhost: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

5) Restore the /etc/login.defs

[root@ci-vm-10-0-105-117 ~]# cat /etc/login.defs | grep 'SYS_'
SYS_UID_MIN               201
SYS_UID_MAX               999
SYS_GID_MIN               201
SYS_GID_MAX               999

6) Remove the cache and restart sssd

[root@ci-vm-10-0-105-117 ~]# systemctl stop sssd; rm -rf /var/lib/sss/db/*; systemctl start sssd

7) Check the authentication again 

[root@ci-vm-10-0-105-117 ~]# ssh -l foo100@example1 localhost
foo100@example1@localhost's password: 
Activate the web console with: systemctl enable --now cockpit.socket

This system is not registered to Red Hat Insights. See https://cloud.redhat.com/
To register this system, run: insights-client --register

Last failed login: Tue Aug 11 07:51:49 EDT 2020 from ::1 on ssh:notty
There were 3 failed login attempts since the last successful login.
Last login: Tue Aug 11 07:42:54 2020 from ::1
Could not chdir to home directory : No such file or directory
[foo100@example1@ci-vm-10-0-105-117 /]$ id 
uid=1200(foo100@example1) gid=1200(test_bar) groups=1200(test_bar) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[foo100@example1@ci-vm-10-0-105-117 /]$ logout
Connection to localhost closed.
[root@ci-vm-10-0-105-117 ~]# 

Thus from above steps marking the bug verified.

Comment 10 errata-xmlrpc 2020-11-04 01:51:21 UTC
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 (authselect 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/RHEA-2020:4503