On Fri, Mar 07, 2008 at 11:08:19AM +0000, Darren J Moffat wrote: > Nicolas Williams wrote: > >So I think the question "how does [the screen lock program] support > >pam_setcred()?" just doesn't make much sense. The answer should be: "it > >calls pam_setcred(), but doing so has little or no impact on the > >unlocked session." > > Except in the case of a module like pam_krb5.so or pam_dhkeys.so because > those update hosts specfic cred state for that user rather than process > specific cred state. In the pam_krb5 case calling pam_setcred() in the > screen saver updates your /tmp/krb5cc_<uid> cred cache. In the > pam_dhkeys.so pam_setcred updates your keylogin status in keyserv(1M).
I know, and that's *very* useful, but the point is that fundamental characteristics of the session won't change as a result of calling pam_setcred() in a screen lock program. > What pam_unix_cred.so does on the other hand is specfic to the process > because it update process privilege sets and audit context. Right. This still matters because auditing is done in the context of the screen lock program, so any changes to auditing policy should take effect when the screen lock program calls pam_setcred() -- but again, the auditing characteristics of the remainder of the session remain unchanged.
