Ray, any idea?

It should work. Two possibilities come to mind:

1. In RHEL-8 it's not very tolerant of typos. If the user types the wrong password first, and then the right password second, GDM assumes systemd will purge the wrong password from the kernel keyring, but it doesn't, so GDM then passes the first (wrong) password onto gnome-keyring. In RHEL 9 GDM always passes the last password, not the first password. We could backport that bug fix.

2. Maybe an selinux issue? It would be interesting to know if enforcing=0 works.

Hi Ray, thanks for the explanation. I see what you mean (concatenated passwords in kernel keyring) but thats not the problem. The password in kernel's keyring is the right one. For the sake of reducing complexity I have setup four vm (cs8, cs9, f36, f37). All are working as expected only the cs8 one _not_.


CS9 says:

# journalctl -b |grep autologin
Dez 07 20:14:35 c9.localdomain gdm-autologin][1163]: gkr-pam: unable to locate daemon control file
Dez 07 20:14:35 c9.localdomain gdm-autologin][1163]: gkr-pam: stashed password to try later in open session
Dez 07 20:14:36 c9.localdomain gdm-autologin][1163]: pam_unix(gdm-autologin:session): session opened for user test(uid=1202) by (uid=0)
Dez 07 20:14:36 c9.localdomain gdm-autologin][1163]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring

and users gnome keyring IS unlocked.



CS8 says:

# journalctl -b|grep autolog
Dez 07 20:06:08 c8.localdomain gdm-autologin][1286]: pam_unix(gdm-autologin:session): session opened for user test by (uid=0)

[root@c8 ~]# ausearch -m avc
<no matches>

and users gnome keyring is NOT unlocked.

So, the same behaviour as on the workstation.

Are you sure that RHEL8 does support this login chain? 

/etc/pam.d/gdm-autologin and /etc/pam.d/system-auth are in CS8 and CS9 exactly the same also

# LANG=C authselect current 
Profile ID: sssd
Enabled features:
- without-nullok



c9 ~]# rpm -q gdm pam
gdm-40.1-18.el9.x86_64
pam-1.5.1-14.el9.x86_64


c8 ~]# rpm -q gdm pam
gdm-40.0-25.el8.x86_64
pam-1.3.1-24.el8.x86_64

thanks for the clarification and detailed explanation. it *should* work by design, but it's possible a defect snuck in and that feature is generally broken at the moment (or less likely it's only broken in certain configurations).

I'm currently on medical leave but should be back on friday and will try to reproduce then and give further feedback.

JFI: I took a look into vanilla source code of gdm 40.0 (CS8) and 40.1 (CS9) and indeed as you said pam_gdm.c has the mentioned loop
to iterate through multiple passwords. Just for clarification; I use just one password (with one input attempt at boot LUKS prompt). 
Get well soon.

I reproduced the issue. Looking at the code, the function is this:

int•
pam_sm_authenticate (pam_handle_t  *pamh,•
                     int            flags,•
                     int            argc,•
                     const char   **argv)•
{•
#ifdef HAVE_KEYUTILS•
        int r;•
        void *cached_password = NULL;•
        key_serial_t serial;•
•
        serial = find_key_by_type_and_desc ("user", "cryptsetup", 0);•
        if (serial == 0)•
                return PAM_AUTHINFO_UNAVAIL;•
•
        r = keyctl_read_alloc (serial, &cached_password);•
        if (r < 0 || r != strlen (cached_password))•
                return PAM_AUTHINFO_UNAVAIL;•
•
        r = pam_set_item (pamh, PAM_AUTHTOK, cached_password);•
•
        free (cached_password);•
•
        if (r < 0)•
                return PAM_AUTH_ERR;•
        else•
                return PAM_SUCCESS;•
#endif•
•
        return PAM_AUTHINFO_UNAVAIL;•
}•

My first guess was then... Maybe HAVE_KEYUTILS isn't defined?

Indeed running

╎❯ objdump --disassemble /lib64/security/pam_gdm.so

shows pam_sm_authenticate is basically just returning PAM_AUTHINFO_UNAVAIL (which has value 0x9)

0000000000000700 <pam_sm_authenticate@@Base>:
 700:   f3 0f 1e fa             endbr64 
 704:   b8 09 00 00 00          mov    $0x9,%eax
 709:   c3                      retq   
 70a:   66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)

So there must be a build system snafu. It probably got introduced when switching from autotools to meson.

It seems keyutils doesn't ship a pkgconfig file:

╎❯ rpm -ql keyutils-libs-devel |grep pkgconfig
╎❯

Looks like a pkgconfig file wasn't added until version 1.6 of keyutils, and we ship 1.5.10 .

We should be able to make GDM look for it a different.

Created attachment 1932209 [details]
Fix LUKS password handling

This attachment adds the two fixes discussed in this bug.

Leon, would you mind testing the new package once it's available?

For convenience, I've put a scratch build here: https://people.redhat.com/rstrode/2150649/

(In reply to Michael Boisvert from comment #12)
> Leon, would you mind testing the new package once it's available?

A quick test shows that the keyring of the user gets unlocked.
Also, mistyping at the LUKS prompt and enter the correct one afterwards works.

Looks great! Thanks!

(In reply to Leon Fauster from comment #14)
> (In reply to Michael Boisvert from comment #12)
> > Leon, would you mind testing the new package once it's available?
> 
> A quick test shows that the keyring of the user gets unlocked.
> Also, mistyping at the LUKS prompt and enter the correct one afterwards
> works.
> 
> Looks great! Thanks!

Thank you for your timely testing!

I am still using this patched gdm version and noticed two things. Albeit not sure how related it is:

## 1 ##

SElinux alerts since then. A lot of entries looking like:

# ausearch -m avc |tail -5
----
time->Thu Dec 22 12:34:49 2022
type=PROCTITLE msg=audit(1671708889.353:54): proctitle=67646D2D73657373696F6E2D776F726B6572205B70616D2F67646D2D6175746F6C6F67696E5D
type=SYSCALL msg=audit(1671708889.353:54): arch=c000003e syscall=250 success=yes exit=23 a0=b a1=201e571c a2=55d1e1897d20 a3=17 items=0 ppid=2897 pid=2909 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1671708889.353:54): avc:  denied  { read } for  pid=2909 comm="gdm-session-wor" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=key permissive=0

# rpm -qf /usr/libexec/gdm-session-worker
gdm-40.0-27.el8.x86_64


## 2 ##

Setup/gnome keyring

My local setup has a user/password pair that uses a password different to the luks one. Just the keyring of the user has the password manually changed to the LUKS one. Booting up, autologin and keyring unlock worked as said. 
Off and on I switch the user session to work with a different user/gnome-session, and then back the "autologin" user. This is all done without rebooting. 

Now, I noticed that the password of the (autologin) user's keyring is set to the account password somewhow back again! Two questions raises up; does the PAM layer resets the keyring password automagically? And how can this happen without the original LUKS password to change it back to the local system password? Because the content of the gnome keyring are still there and accessible. Is such setup with different passwords supported?

Its weird, I hope that its understandable.

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 (gdm 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-2023:2779