On Tue, 2006 Aug 01 11:29:19 +0200, Thorsten Kukuk wrote: > > pam_syslog exists on OpenPAM and Linux-PAM as far as I know. OpenPAM has openpam_log(), so #ifdefs would be needed in any event. But this isn't a problem. (Not as much as pam_syslog() wanting a pam_handle_t, anyway...) > But if you wish to get your module upstream, you have to use the specific > functions of that project and follow their coding style. > If you don't wish to do this, you should not submit it upstream but > maintain it as seperate module. I do intend to submit the module to the existing projects---though at the same time, I'd like to avoid large changes between them, so that cross-pollination remains straightforward. > > > > expose_account > > > > try_first_pass > > > > use_first_pass > > > > use_mapped_pass > > > > > > We don't need them at all. > > > > Okay. Should the module accept-but-ignore them? > > I would ignore them complete. Sounds good. It appears that use_first_pass is the only option of interest anymore, and since the module doesn't have password-prompting code anyway, it shouldn't make a difference either way. > > (I see the "4. Generic optional arguments" section in the manual states > > "Here we list the generic arguments that all modules can expect to be > > passed," which implies that this ought to be the case.) > > The chapter was changed for the new documentation (could be found in > CVS and I uploaded them now to www.kernel.org). Excellent! Yes, I was referring to the online copy at kernel.org. > > Erm... the "2.2 Other functions provided by libpam" section states "The > > pam_fail_delay() function provides the mechanism by which an application or > > module can suggest a minimum delay (of micro_sec micro-seconds). Linux-PAM > > keeps a record of the longest time requested with this function." > > > > Am I missing something, or is the manual out of date? > > "can suggest". This does not mean you have to use it. You should only > use if it it makes sense. For exmaple if you write an module, which > sets the delay to a special value for special purpose. A standard module > does not need this function. Okay. I will remove the fail_delay bits from the module and the documentation. > Only because a function exist it does not mean you need to use it. You > refuse to use the other non standard PAM functions, too, so why not > this one? Whoa, stop right there---I didn't say that I _refuse_ to use any Linux-PAM-specific functions. I only said that, up until now, I had refrained (i.e. held back) from doing so. I used pam_fail_delay() because the docs discussed how to #ifdef its use cleanly, and it looked like a potentially helpful feature. A case of, "well, why not throw this in?" :) --Daniel -- NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? EMAIL1 = skunk@xxxxxxxxxx ## don't smell bad--- (/o|o\) / EMAIL2 = skunk@xxxxxxxxxxxx ## it's the people who < (^),> WWW = http://www.******.org/ ## annoy them that do! / \ -- (****** = site not yet online) _______________________________________________ Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list
