Talk:PAM

Accuracy of PAM#Examples

The accuracy of PAM#Examples was discussed at the forums. I suggest to

1. Mention that nullok inverts pam_unix.so default behavoiur of not allowing blank passwords.
2. Remove the claim that

- the latter being what pam_permit.so is used for.

And state that as is, the pam_permit.so line has no effect with this configuration due to the way pam treats an optional module.

02:05, 23 April 2019 (UTC)

Edit: I tried to review this thread at 13 April 2024. My first difficulty was to see the content of the article back then. Was it as in Special:Diff/571854/cur? 13 April 2024 (UTC)

Regid (talk)

Technically it's used as a fallback in case no other modules has contributed to the return code. According to manual pam_unix(8), pam_unix can return PAM_IGNORE which leaves pam_permit the only one in this stack, hence pam_permit's return code is used as the final result. This is a common practice to avoid being locked from the system accidentally.

FrederickZh (talk) 20:07, 5 January 2021 (UTC)

Good point to discuss. The purpose of PAM#Examples was, as it says with reference to the warning, to illustrate how an single erroneous change (of switching required and optional) can havoc the stack. For that it referenced it default pambase, which was later updated in 08/2021.[1] Explaining how and when nullok takes effect and when pam_permit applies, was not necessary to show the point (and both would have required deeper dive, yes). Since, the stack and login.defs have changed more; the example does not work anymore. A simple example following current system-auth (to follow the section) would be best, because we don't want users locking themselves out when they try it. Ideas how to update it?

--Indigo (talk) 18:15, 26 May 2022 (UTC)

Revisiting, I added the reference. Perhaps another example would be to fiddle with pam_faillock.so to intentionally break that, but it would need a little more verbose.? --Indigo (talk) 20:30, 15 March 2024 (UTC)