Re: trouble with pam

Simon Horman <[email protected]> Thu, 24 Jan 2013 09:53:30 +0900
Newsgroups gmane.mail.perdition.user
Message-ID <[email protected]>
On Mon, Aug 27, 2012 at 03:35:15PM -0700, David Severance wrote:
> When we originally implemented perdition v1.17 on RHEL4 several years 
> ago we had a customized the /etc/pam.d/perdition file to use the 
> pam_access.so module so we could lock out accounts for 
> administrative/maintenance purposes. This worked well for many years.
> 
> Within the last year we upgraded to RHEL5 and perdition 1.19rc4 and then 
> rc5. It would appear that since this update perdition no longer seems to 
> pay any sort of attention to the contents of the pam file and will 
> always assume success. Nothing seems to be logged either unlike before. 
> Although we are now compiling perdition to be located in /usr/perdition 
> with it's conf files in /etc/perdition I don't see how that would affect 
> pam operations, at least I would think it shouldn't. ldd on perdition 
> does show pam libraries being linked. Any ideas?

Perhaps perdition is being built without PAM support. This could occur for
one of several reasons:

* --disable-pam was passed as a command-line argument to ./configure
* Perdition was unable to find security/pam_appl.h at configure-time
* Perdition was unable to find the symbol pam_authenticate in libpam
  at configure-time.

In all cases of the above cases something relating to pam being disabled
should show up in the output of ./configure.

______________________________________________
Perdition-users mailing list
[email protected]
http://lists.vergenet.net/listinfo/perdition-users