Nicolas Williams wrote: > The changes?: > > - export pam_set_data() and pam_get_data() to the PAM apps; > > - make libpam call pam data cleanup functions when pam_end is called, > delaying the calling of cleanup functions when pam data is replaced; > > - establish conventions for modules to prompt apps, not for usernames > and passwords, but for GSS-API/Kerberos contexts, tokens, creds, > etc...; > > - in fact, binary prompts aren't all that necessary here, as long as > pam_set_data() and pam_get_data() are available to the app for > exchanging non-string data with PAM modules; > > - then make some utility functions to hide the conventions mentioned > above (e.g., pam_gss_authenticated()). > > Only the first two items are actual changes to PAM. And they're small > changes, methinks. > > Is there any reason NOT to do this? I'm not convinced that this approach > is bad. In fact, I'm getting more and more convinced it's good. But it > wouldn't pay off till several apps where modified to use this approach. This has been a long and fragmented thread. Could you write up a summary of why the above is what you want and what each bit buys you/us? I count three changes to libpam and can think of reasons why the first two may well be backwardly incompatible, but without seeing the 'whole thing' in context, I don't know how to suggest an alternative. Thanks Andrew
