Re: Disable TRUST authentication by using ClientAuthentication_hook

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fabrízio de Royes Mello <fabrizio(at)timbira(dot)com(dot)br>
Cc: Guillaume Lelarge <guillaume(at)lelarge(dot)info>, kpi6288(at)gmail(dot)com, PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Disable TRUST authentication by using ClientAuthentication_hook
Date: 2018-07-13 13:51:19
Message-ID: 23124.1531489879@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= <fabrizio(at)timbira(dot)com(dot)br> writes:
> 2018-07-13 9:01 GMT-03:00 Guillaume Lelarge <guillaume(at)lelarge(dot)info>:
>> 2018-07-13 13:57 GMT+02:00 <kpi6288(at)gmail(dot)com>:
>>> 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Łukasz Jarych 2018-07-13 13:56:18 Re: Handlind booleans Postgresql-Access
Previous Message Adrian Klaver 2018-07-13 13:36:25 Re: Handlind booleans Postgresql-Access