On Mon, 30 Apr 2001, Nicolas Williams wrote: > > > Why keep extending the account authorization code in MIT krb5 when PAM > > > is available? (Short answer: MIT krb5 knows not PAM at this moment, sigh). > > A while ago djm submitted some patches to fix that. I've asked him to > > check a couple of things, but I would like to get something like it in > > soon. My main issue was avoiding code duplication -- can we use a > > krb5 PAM module, and a PAM-based login program with little or no > > krb5-specific stuff, and a stub implementing the PAM API (but just for > > the krb5 module, with no configuration options) for systems that don't > > have PAM already, or do we have to maintain both flavors of login > > code? If we can do the former, it seems like the far better approach, > > even if it's a bit more work in the short term. > Well, Linux-PAM is rather portable (*)and it's distributed under a BSD > license... > And most modern Unix and Unix-like OSs support PAM. If not PAM, then > SIA. Even on those which don't support PAM, it seems that efforts are being made to make Linux-PAM (OpenPAM?) available. I've seen reports that the PAM libraries (not the modules yet -- but isn't the library all that's required here?) have been successfully ported to AIX and Tru64. Steve Langasek postmodern programmer
