On Nov 19, 2009, at 4:29 AM, Darren J Moffat wrote: > Wyllys Ingersoll wrote: >> Darren J Moffat wrote: >>> Wyllys Ingersoll wrote: >>>> Gary Winiger wrote: >>>> >>>>> My personal recommendation: Develop a pam_pkinit (or similarly >>>>> named) module >>>>> with a separate man page. Have that man page describe the >>>>> interactions >>>>> between pam_pkinit and pam_krb5. >>>>> >>>>> Thanks for the extra time, >>>>> Gary.. >>>> >>>> Will F is on vacation for a bit longer. I believe the main >>>> reason he >>>> did not >>>> want to create a new module was that it would result in an almost >>>> identical >>>> body of code. Perhaps the existing pam_krb5 tree can be >>>> refactored or >>>> the build process could be modified so that the 2 modules (should >>>> he >>>> choose >>>> to take your advice) share a common body of code except for the >>>> places >>>> where the logic differs for standard krb5 vs pkinit. >>> Hence my suggestion of keeping pam_krb5 as is and using a pkinit >>> module >>> option. >>> >>> I personally think this is a perfect use case for module options >>> and I >>> think that in the long run having two separate modules will actually >>> turned out to be a problem. So I would prefer a pkinit module >>> option, >>> that should be trivial to implement. >>> >> I would be OK with adding options in this case as well. Having >> the options >> visible in the pam.conf would make it obvious to the admin that the >> 2 instances in the stack have different uses and would, I think, >> address >> Gary's concern about confusion over having 2 pam_krb5 entries in the >> same stack. > > Indeed, the difference is syntax more than anything else eg: > > other auth required pam_krb5.so pkinit > > versus > > other auth required pam_krb5_pkinit.so > > White space versus an underscore. I like module options, when used > properly, and to me this is a perfect case of proper use of a module > option. The code for password based versus PKINIT based Kerberos > authentication is in the very high 90% range of common code, in fact > it is pretty much just a flag to a lower level API. Gary however > seems to prefer a separate module with the common code factored into > a library.
I have to agree with the analysis that supporting a "pkinit" module argument is very easy. Note that so far my implementation of pkinit support in our pam_krb5 is about 50 new lines of code. Taking the other approach of refactoring the common code in to a lib shared between pam_krb5.so and pam_krb5_pkinit.so would be significantly more work with more opportunity for bugs I believe. Note, I'm on vacation until Nov 30. -- Will Fiveash Sun Microsystems Inc. Austin, TX, USA (TZ=CST6CDT)
