On Sun, 4 Mar 2001, Nicolas Williams wrote: > On Sun, Mar 04, 2001 at 02:12:58PM -0600, Steve Langasek wrote: > > On Sun, 4 Mar 2001, Nicolas Williams wrote: > > Incidentally, does anyone have a guide for cross-platform PAM programming, > > that covers all the minor incompatibilities one's likely to run into when > > writing modules/apps? I think the question has come up on the mailing list > > before, but I don't remember if anyone has done any compilation work on it > > yet. > http://www.dementia.org/~shadow/pam.html Ah. Bookmarked then, thanks. :) Yes, I'd seen this page before and just didn't remember it. It seems to be somewhat out-of-date (Last Modified: Thursday, 14-Jan-99 16:26:57 GMT). Does anyone know if Derick intends to maintain this page long-term? > > In general this is a reasonable workaround, but I can easily see cases where > > calling the conversation function once versus multiple times would make a > > difference. Certainly, it will always be (marginally) more efficient to call > > the conversation function as few times as possible, so all other things being > > equal it makes sense for pam_krb5 to do as it does now; but there may also be > > cases where each call to the conversation function is very expensive > > (cryptographic setup/teardown?), or where a set of messages are interrelated > > and should therefore be passed together so that the relationship between them > > is evident. E.g., what if you have a conversation function that tacks > > headers/footers onto each message set? What if your conversation function > > displays the messages using a web page? (Not a hypothetical scenario; I have > > such a conversation function that works quite well with other pam_krb5 > > implementations.:) > Ah, but do those modules use krb5_get_init_creds_password()? Or do they > use the krb5_get_in_tkt_with_password() API? The difference is in how to > do password aging. The former does all the work, the latter merely > returns an error when the password is expired (unless the target > principal name is a password-changing service). No, of course they don't use krb5_get_init_creds_password(). If they did, I would never have noticed the problem with Frank's module. :D Actually, I'm going to be making some changes locally to pam_krb5 so that the changing of expired passwords is moved to the pam_chauthtok() stage where it belongs according to the spec (which means no longer using krb5_get_init_creds_password()). I have a genuine need for module stacking in the password-changing phase, so having pam_krb5 do this directly in the auth phase doesn't cut it for me. > > So there may not be an /absolute/ need to send multiple prompts in one go, but > > it's certainly unfortunate if we have to give up this functionality in > > exchange for portability. > Agreed. For now I'll modify my version of this module to support an > option to prompt one prompt at a time. Have you talked to Frank about including your fixes in his next release? (I've been cc:ing him on this thread because it's relevant to making his module work under Linux, but I have no idea if he's reading. :) I agree with your assessment that Frank's pam_krb5 module is the most functionally-complete implementation available to date, which is a good reason to prevent code forking here if possible... Steve Langasek postmodern programmer
