New and improved pam_exec module

[Thorsten Kukuk]

On Mon, Jul 31, Daniel Richard G. wrote:

> > The pam_exec line is from a pam_exec implementation calling openlog/closelog.
> > This is very bad. You loose the information, which application called
> > pam_exec, you destroy the syslog options of the main applications and you
> > will get problems with threaded applications.
> >  
> > The pam_unix one looks more correct. You should always use pam_syslog.
> > We will not accpet self written logging functions again in Linux-PAM,
> > we are happy that all are replaced with pam_*() functions now.
> 
> Hmm. I had refrained from using Linux-PAM-specific functions, bearing in 
> mind compatibility with OpenPAM et al., but I suppose the log() function 
> can be #ifdef'ed appropriately. I'll make this change.

pam_syslog exists on OpenPAM and Linux-PAM as far as I know.
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.
 
> > > * The module will accept the following options, but I'm not sure what 
> > >   exactly it should do (if anything) with them:
> > > 
> > > 	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.

> (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).

> > > * I'm a bit unclear on how pam_fail_delay() is supposed to work. Is the 
> > >   manner in which I handled it---and described it in the documentation---at 
> > >   all incorrect?
> > 
> > You should not call pam_fail_delay() from a module. The application has to
> > set it. Else you will overwrite defaults which the sysadmin set.
> 
> 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.

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?

  Thorsten

-- 
Thorsten Kukuk         http://www.suse.de/~kukuk/      kukuk at suse.de
SUSE LINUX Products GmbH       Maxfeldstr. 5       D-90409 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = 8C6B FD92 EE0F 42ED F91A  6A73 6D1A 7F05 2E59 24BB