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

_______________________________________________
Pam-list mailing list
Pam-listredhat.com
https://listman.redhat.com/mailman/listinfo/pam-list

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]