This is the continuation to the discussion that we had in the
Here, I like to add some details in 20.2.6. PAM authentication section.
Can someone review and make changes, if required? Thanks.
Eh, those extensions are only valid if you use PAM with a shadow
file, no? You shouldn't need root if you use say PAM-with-LDAP?
Also, it strikes me that granting the postgres user read access to the
shadow file is probably very poor security practice, and not something
I would want to recommend without considerable thought. What we should
say, rather, is that PAM auth is likely to fail if your PAM is set up
to use the shadow file rather than an auth source such as LDAP which
does not require privileged file access.
Is this change Ok?
*** client-auth.sgml.orig Tue Aug 21 16:52:45 2007
--- client-auth.sgml Tue Aug 21 17:02:52 2007
*** 987,992 ****
--- 987,1001 ----
and the <ulink url="http://www.sun.com/software/solaris/pam/">
<systemitem class="osname">Solaris</> PAM Page</ulink>.
+ If your PAM is set up to use the shadow file, the PAM authentication
+ is likely to fail for local UNIX users because the postgresql server
+ is started by a non-root user. However, this is not an issue
+ when LDAP or other authentication mechanism is used.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not