Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Dan Yefimov (dannf15.lightwave.net.ru)
Date: Wed Nov 12 2008 - 09:28:34 CST
On 12.11.2008 5:18, Jesse Zbikowski wrote:
> This issue was raised a couple of times this spring without response.
> I would like to know, if there is more than one path for
> authorization in the PAM stack, which one actually succeeded. For
> example, say I have a PAM configuration file like this:
> auth sufficient pam_first.so
> auth sufficient pam_second.so
> acct sufficient pam_first.so
> acct sufficient pam_second.so
> The behavior I want is: whichever module succeeds for authorization,
> use the same module when the application makes an accouting request.
> The module pam_tacplus.so is "well-behaved" in this regard, in that
> acct will not succeed unless auth already did. pam_radius_auth.so
> however, at least in my configuration, it is happy to succeed in the
> acct request after a different module handled the auth request, which
> breaks my scheme.
Thus your scheme is vulnerable in that respect. Rework it. Read pam.conf manual
and look for extended syntax there.
> If it is not possible to get this behavior from PAM out of the box,
> would it make sense to write a custom PAM module to handle this logic?
> That is, my module would internally call pam_authenticate() /
> pam_acct_mgmt() on other PAM services, according to my specifications.
Yes, that's possible, but such a module would be hardly dependent on PAM
internals that can be changed without notice with each PAM release.
> With reference to the original posts on this topic: right now I would
> be if my application could figure out whether it was pam_first.so or
> pam_second.so which succeeded, perhaps via pam_get_item()
PAM was developed with application independence on authentication methods and
their order in mind, so that is generally impossible. If your application is
dependent on modules used and/or their order, it is broken in that respect.
Sincerely Your, Dan.
Pam-list mailing list