New and improved pam_exec module

[Daniel Richard G.]

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 at iskunk.org        ##  don't smell bad---    (/o|o\) /
EMAIL2 = skunk at alum.mit.edu      ##  it's the people who   < (^),>
WWW    = http://www.******.org/  ##  annoy them that do!    /   \
--
(****** = site not yet online)