Bug 1676385

Summary: pam_sss with smartcard auth does not create gnome keyring
Product: Red Hat Enterprise Linux 8 Reporter: adam winberg <adam.winberg>
Component: sssdAssignee: Sumit Bose <sbose>
Status: CLOSED ERRATA QA Contact: sssd-qe <sssd-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.0CC: aakkiang, grajaiya, jhrozek, lslebodn, mzidek, pbrezina, sbose, sgoveas, spoore, sveerank, tscherf, wchadwic
Target Milestone: rc   
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: sssd-2.2.0-17.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-05 22:34:01 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:
Attachments:
Description Flags
gnome keyring login unlocked none

Description adam winberg 2019-02-12 07:10:00 UTC
Description of problem:
I want to auto unlock the gnome keyring on login. If the 'login' keyring does not exist it should be created using the smartcard PIN provided by the user as password. This worked in RHEL7 with pam_pkcs11 but does not seem to work with pam_sss, i get the following error:

gdm-smartcard][19194]: gkr-pam: no password is available for user

It seems like pam_sss does not let other pam modules use the provided PIN even though 'forward_pass' is specified. 


/etc/pam.d/gdm-smartcard:
auth        substack      smartcard-auth
auth        optional      pam_gnome_keyring.so 
auth        include       postlogin

account     required      pam_nologin.so
account     include       smartcard-auth

password    include       smartcard-auth

session     required      pam_selinux.so close
session     required      pam_loginuid.so
session     optional      pam_console.so
session     required      pam_selinux.so open
session     optional      pam_keyinit.so force revoke
session     required      pam_namespace.so
session     include       smartcard-auth
session     optional      pam_gnome_keyring.so auto_start
session     include       postlogin


Version-Release number of selected component (if applicable):
sssd-2.0.0-21.el8.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Add pam_gnome_keyring to /etc/pam.d/gdm-smartcard
2. Login using pam_sss and smartcard
3.

Actual results:
'login' keyring is not created.

Expected results:
'login' keyring should be created using my smartcard PIN as password

Additional info:

Comment 1 Sumit Bose 2019-02-12 07:25:17 UTC
Hi,

thank you for the report. You are right, currently the PIN is not put on the PAM stack for other modules even if 'forward_pass' is specified. This is a bug and I think there is currently no workaround.

bye,
Sumit

Comment 6 adam winberg 2019-06-28 12:57:31 UTC
Are there any plans on fixing this bug?

Comment 8 Sumit Bose 2019-08-19 15:37:38 UTC
Upstream ticket:
https://pagure.io/SSSD/sssd/issue/4067

Comment 9 Sumit Bose 2019-08-23 16:53:51 UTC
Master:
 - e989620bd2b4f7094dee3ef740ba92d0cf45d0c8

Comment 18 Scott Poore 2019-09-04 12:54:06 UTC
Verified.

Version ::

sssd-2.2.0-18.el8.x86_64

Results ::

Add auth and session entries for pam_gnome_keyring.so to gdm-smartcard:

# cat gdm-smartcard
auth        substack      smartcard-auth
auth	    optional      pam_gnome_keyring.so
auth        include       postlogin

account     required      pam_nologin.so
account     include       smartcard-auth

password    include       smartcard-auth

session     required      pam_selinux.so close
session     required      pam_loginuid.so
session     optional      pam_console.so
session     required      pam_selinux.so open
session     optional      pam_keyinit.so force revoke
session     required      pam_namespace.so
session     include       smartcard-auth
session     optional      pam_gnome_keyring.so auto_start
session     include       postlogin

Add forward_pass to the auth pam_sss.so entry of smartcard-auth:

# cat smartcard-auth 
# Generated by authselect on Wed Sep  4 07:13:32 2019
# Do not modify this file manually.

auth        required                                     pam_env.so
auth        sufficient                                   pam_sss.so allow_missing_name forward_pass
auth        required                                     pam_deny.so

account     required                                     pam_unix.so
account     sufficient                                   pam_localuser.so
account     sufficient                                   pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required                                     pam_permit.so

session     optional                                     pam_keyinit.so revoke
session     required                                     pam_limits.so
-session     optional                                    pam_systemd.so
session     optional                                     pam_oddjob_mkhomedir.so umask=0077
session     [success=1 default=ignore]                   pam_succeed_if.so service in crond quiet use_uid
session     required                                     pam_unix.so
session     optional                                     pam_sss.so


Before Login:

# find /home/ipauser1/.local/share/keyrings/
/home/ipauser1/.local/share/keyrings/

After Login with smartcard:

# find /home/ipauser1/.local/share/keyrings/
/home/ipauser1/.local/share/keyrings/
/home/ipauser1/.local/share/keyrings/login.keyring
/home/ipauser1/.local/share/keyrings/user.keystore

I will also attach screen capture showing the login unlocked.

Comment 19 Scott Poore 2019-09-04 12:55:00 UTC
Created attachment 1611501 [details]
gnome keyring login unlocked

this screenshot shows the login unlocked on first time login with smart card.

Comment 21 errata-xmlrpc 2019-11-05 22:34:01 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, 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/RHSA-2019:3651