On Tue, 8 May 2001, Bruce Momjian wrote:
> > The PAM support patch concerns me --- it looks like yet another chunk
> > of code that will tie up the postmaster in a single-threaded
> > conversation with a remote daemon that may or may not respond promptly.
> > I recommend holding off on this until we think about whether we
> > shouldn't restructure the postmaster to do all authentication work in
> > per-client subprocesses.
>
> I have not idea what PAM is. If it is a valuable feature, we can
> install it. But if it is yet another authentication scheme, it could
> add more confusion to our already complicated setup. Seems you are
> saying it is the latter, which is fine with me.
PAM is a universal interface to many authentication schemes. If PostgreSQL
supports PAM properly, it can instantly support many different types of
authentication, such as UNIX, Kerberos, RADIUS, LDAP, or even
Windows NT domain authentication. Solaris and most modern Linux
distributions (certainly Red Hat) support PAM:
http://www.sun.com/solaris/pam/
http://www.kernel.org/pub/linux/libs/pam/
PAM modules are very flexible -- they are even stackable. I've used PAM to
allow the UW IMAP server running on Red Hat Linux to get its passwords
either from UNIX authentication or from a Windows NT server, for example.
Given that this has the potential to reduce the number of places that
system administrators have to maintain passwords, I'd call it a win
overall, except for that pesky single-threaded issue. You should keep in
mind, though, that some PAM calls won't involve calls to daemons that
might not be responsive. Let's say PAM is configured to check
UNIX authentication (/etc/passwd and /etc/shadow) for passwords -- there
is no daemon involved, just calls to C libraries that will return
promptly. If the PAM config file had something like LDAP authentication
indicated, you would have a potential issue if the LDAP server did not
respond.
As long as this limitation was documented, though, this would be a very
valuable addition. A release note saying that the feature was
experimental, and outlining the limitations in the face of choosing an
authentication scheme that may fail to answer might be appropriate.
--Richard Bullington-McGuire <rbulling@microstate.com>Chief Technology Officer, The Microstate CorporationPhone:
703-796-6446 URL: http://www.microstate.com/PGP key IDs: RSA: 0x93862305 DH/DSS: 0xDAC3028E
