On Thu, Apr 16, 2015 at 9:55 AM, Bernd Helmle <maili...@oopsware.de> wrote: > 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.
But... the user could use password authentication with the password set to "x" and that would be insecure, too, yet not prevented by any of this. I think it's pretty hard to prevent someone who has filesystem-level access to the database server from configuring it insecurely. Of course, it's fine for people to make changes like this in their own copies of PostgreSQL, but I'm not in favor of incorporating those changes into core. I don't think there's enough general utility to this to justify that, and more to the point, I think different people will want different things. We haven't, for example, ever had a request for this specific thing before. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers