New and improved pam_exec module

Thorsten Kukuk kukuk at suse.de
Mon Jul 31 09:50:04 UTC 2006


On Sun, Jul 30, Daniel Richard G. wrote:

> * Instead of directly exec'ing a named program, the module invokes a 
>   /bin/sh command string, for greater flexibility.

Which flexibility should this give?
 
> * Is the syslog interaction properly following convention? I noticed an 
>   inconsistency in the formatting of syslog messages between pam_exec and 
>   pam_unix (both invoked from sshd)...
> 
> 	Jul  7 15:12:53 bassoon pam_exec[28567]: Command exited with status 0
> 	Jul  7 15:12:53 bassoon sshd[28567]: (pam_unix) session opened for 
> 	user skunk by (uid=0)
> 
>   ...but am uncertain of how things ought to be done here.

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.

> * 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.
 
> * 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.
 
> Attached is a patch against current CVS to pam_exec.c and pam_exec.8.xml. 
> It is gzipped, owing to its size.

I would prefer to handle such large changes like the kernel developers
do: A lot of small patches for every new functionality, so that it
is possible to review and discuss every change and not one very big
patch.

  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




More information about the Pam-list mailing list