=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabrizio@xxxxxxxxxxxxxx> writes: > 2018-07-13 9:01 GMT-03:00 Guillaume Lelarge <guillaume@xxxxxxxxxxxx>: >> 2018-07-13 13:57 GMT+02:00 <kpi6288@xxxxxxxxx>: >>> I’d like to disable the TRUST authentication method for certain servers >>> where modification of pg_hba.conf and restarting a service is fairly easy >>> for a number of users. >> I'm not sure this is such a good idea. You may need the trust >> authentication method, for example if you forgot the superuser password. >> Otherwise, there's good chance you might use the ClientAuthentication hook >> to do what you want. > If you're an server admin you can disable the extension (editing > shared_pre_load_libraries GUC), change password and then enable the > extension again... Or more to the point: exactly what is the threat model here? ISTM that someone with enough privilege to alter pg_hba.conf can probably suppress loading of an extension too, so that the security added by this idea is not just questionable but completely illusory. What would actually move the goalposts a bit is to build a modified server which doesn't have the TRUST code path at all, so that there is no question of installing an extension or not; then somebody who wants to defeat the security needs to be able to replace the server executable. But you don't need any hook if you do that. BTW, the usual way to get around I-forgot-the-superuser-password is to start the server in single-user mode and use that to issue an ALTER USER ... PASSWORD command. As long as your patch doesn't break single-user mode, you don't need any other escape hatch. regards, tom lane