Bug 2182015

Summary: Clarify `/etc/pam.d/sddm` choices
Product: [Fedora] Fedora Reporter: Cristian Le <fedora>
Component: sddmAssignee: Neal Gompa <ngompa13>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 39CC: jgrulich, kde-sig, m, ngompa13, pierluigi.fiorini, rdieter, travier
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 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:

Description Cristian Le 2023-03-27 09:34:56 UTC 
Primarily, I want to raise the question about the line:
```
auth        substack      password-auth
```

Why do we use `substack` instead of `include` here? I have encountered an issue with `pam-u2f`/`pam-fprintd` configured as `sufficient` (haven't thoroughly tested `required`), where when I try to login, it simply hangs. This issue does not occur when I change from `substack` to `include`. Is anyone able to replicate or explain the choice of `substack`?

And another issue prompted by `authselect` in this issue[1] is, why are we using `password-auth`? They have suggested that we should be using `system-auth` instead, because the former is specific for password-like authenthication and stuff like login via fingerprint or yubikeys should be in the more general system-auth. There is an issue of course with gnome-keyring missing a password, which I have raised in the issue, but this seems to be more of a design issue all-around with secret-service/gnome-keyring/pam and passwordless authenthicators.
Comment 1 Fedora Release Engineering 2023-08-16 07:12:34 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.