RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1393057 - unix_chkpwd and /etc/shadow permissions prevent pam_unix from properly authenticating for PostgreSQL
Summary: unix_chkpwd and /etc/shadow permissions prevent pam_unix from properly authen...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pam
Version: 7.3
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-08 18:29 UTC by Matthew Copeland
Modified: 2017-04-03 14:41 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-03 14:41:07 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Matthew Copeland 2016-11-08 18:29:52 UTC
Description of problem:


  If you setup postgresql to use pam authentication, it will fail to authenticate for pam_unix (local account) logins.  It will work for pam_krb5 logins.

  By reading the unix_chkpwd man page, I learned that it can also expect to be sgid in the shadow group.  By adding a shadow group, making /usr/sbin/unix_chkpwd and /etc/shadow owned by root:shadow, and making /usr/sbin/unix_chkpwd suid root and sgid shadow, and finally making /etc/shadow 040 for permissions, I was able to get it to work.  Unfortunately, when the new pam update came down, it blew away the file permissions and changed the ownership back on /usr/sbin/unix_chkpwd.  It started working again, once I changed it back to how I described it.


Version-Release number of selected component (if applicable):


I believe this effects multiple versions, but I haven't checked them all.  

The one I tested on RHEL 7.2 and 7.3 was pam-1.1.8-18 and whatever one comes as the default for RHEL 7.2 with it not yet updated.





How reproducible:

Very reproducible and deterministic.




Steps to Reproduce:



I first figured it out on a 7.3 system.  I took a RHEL 7.2 ISO and installed it into a VM clean, installed postgresql-server and setup a database with a user to match a local user account name.  Next, I changed all of the methods to pam in pg_hba.conf, and restarted postgresql.  I then attempted to connect to localhost using a local user account  (testuser), and got the messages

unix_chkpwd[21460]: check pass; user unknown
unix_chkpwd[21461]: check pass; user unknown
unix_chkpwd[21461]: password check failed for user (testuser)
journal: nweb testxdb 129.237.45.177(37182) authentication: pam_unix(postgresql:auth): authentication failure; logname= uid=26 euid=26 tty= ruser= rhost=127.0.0.1  user=testuser

After making the changes I described above, I tried again, and was able to get authenticated.


(Some of this is from memory, so please forgive if I added an unneeded step as I'm walking through shell history.)

As root:
0. adduser testuser and give it a password.
1. yum install postgresql postgresql-contrib postgresql-server
2. su - postgres
3. initdb
4. exit
5. systemctl start postgresql.service
6. su - postgres
7. createuser testuser
8. modify pg_hba.conf to have all methods changed from trust to pam.
8.?   you may need to modify  postgresql.conf's listen_addresses to be '*'.
9. exit
10. systemctl stop postgresql.service
11. systemctl start postgresql.service
12. su - testuser
13. psql postgres  
14. Enter the password.  When it fails, check the results in /var/log/secure
15. exit # Back to root

The FIX (as root):
16. groupadd shadow
17. chown root:shadow /etc/shadow /usr/sbin/unix_chkpwd
18. chmod 6755 /usr/sbin/unix_chkpwd
19. chmod 0040 /etc/shadow
20. su - testuser
21. psql postgres
22. Enter the password, and you are in.


Actual results:

Unable to login to database.  PAM Authentication fails for correct password.  (I even changed the password to something horribly simple, and retried multiple times to make sure I wasn't typing my long password incorrectly.)

Expected results:

User should be able to login and have it authenticate against the local account.


Additional info:

I saw one place mention this on the web for centos 6 also.  I did see some other pam_unix issues in bugzilla for other services, which may be having similar problems.  I choose to document this for the use case I was having, since I can't be sure without testing it and knowing something about those services.

Comment 1 Matthew Copeland 2016-11-08 18:38:21 UTC
Something I forgot to mention, I did try changing the SELinux policy to permissive as a part of my testing, just to make sure I hadn't missed something in that area.  I still got the same behavior.

Comment 2 Tomas Mraz 2016-11-09 07:59:06 UTC
I do not think we are going to modify the permissions on unix_chkpwd and /etc/shadow. One of the reasons is that it would break requirements of various security profiles. I would recommend either not to use the system account database for PostgreSQL and similar services at all or try to configure authentication to go through sssd as proxy for the local system accounts - it should work.

Comment 4 Red Hat Bugzilla Rules Engine 2017-04-03 14:41:07 UTC
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.


Note You need to log in before you can comment on or make changes to this bug.