24 Jan
2013
24 Jan
'13
5:53 a.m.
On Wed, Jan 23, 2013 at 08:28:17PM -0800, David Severance wrote:
On 1/23/2013 4:53 PM, Simon Horman wrote:
The behaviour you describe above is most likely correct.
But unfortunately perdition isn't quite that clever.
If its still a problem for you I can look into fixing it.
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.
Actually I determined what was behind this issue but haven't been quick
to post what happened. Perdition is compiled will all the correct
options and this was the same binary that was previously being used when
we were successfully using pam_access to limit some users. What changed
was we turned off "authenticate_in" in perdition because we ran into
problems with capacity on our Kerberos service. That was awhile back,
then more recently I noticed that users listed in the
/etc/security/access.conf that pam_access read were not being processed.
I had thought if the pam access rules were listed in the Account section
that they would still be processed since they, the pam rules, were not
in the Auth section. However I'm not overly versed in pam so this may be
a conjuring of my mind as opposed to something that is indeed a real
problem. I just don't know enough about pam to know for sure what the
proper behavior should be.