We have a customer using a patch to harden their PostgreSQL installation (see attached) they would like to contribute. This patch adds the ability to disable "trust" and "ident" authentication at compile time via configure options, thus making it impossible to use these authentication methods for sloppy configuration purposes. This is critical to their software deployment, as stated in their use case description:
<snip> PostgreSQL is deployed as part of a larger technical solution (e.g. a Telecommunication system) and a field engineer has to install/upgrade this solution. The engineer is a specialist in the Telco domain and has only little knowledge of databases and especially PostgreSQL setup. We now want to provide these kinds of users with pre-hardened packages that make it very hard to accidentally expose their database. For this purpose the patch allows to optionally disable the "trust" and "ident" authentication methods. Especially the "trust" mechanism is very critical as it might actually provide useful functionality for our user. Think of an engineer who has to do a night shift upgrade with a customer breathing down his neck to get the system back online. Circumventing all these authentication configuration issues by just enabling "trust" is very easy and looks well supported and documented. (the documentation states the dangers but there are no *big red flags* or something). After finishing the upgrade the engineer forgets to restore the secure configuration, and a malicious attacker later uses this access method to gain access to the database. </snip> Currently the patch adds new configure options --without-trust-auth and --without-ident-auth and makes "peer" authentication default when these options are set. My testing shows that regression tests (which are normally using trust) are still working. This works as far as it goes to Linux and friends, Windows currently is not adressed yet. Maybe its worth to consider making "sspi" the default on this platform instead. There was a discussion some time ago ([1]), but i think the reasoning behind this patch is a little bit different than discussed there. [1] <http://www.postgresql.org/message-id/CAN2Y=umt7cpkxzhaufw7szeckdwcwsuulmh4xphuxkqbtdu...@mail.gmail.com> -- Thanks Bernd
disable_trust_ident_configure.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
