> -----Ursprüngliche Nachricht-----
> Von: Tom Lane <tgl@sss.pgh.pa.us>
>
> > 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...
I am aware of this and all the other points.
> Or more to the point: exactly what is the threat model here?
It is similar like with your garage door: locking it with a simple 50 year-old-key is still better than just clamping
itwith a wedge. It is certainly not as good as enforcing the door and putting a modern and solid lock to it.
> 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.
This is a valid point of concern. However, settings in pg_hba.conf need to be documented to allow modification of IP
addressranges etc. A few people have access to this and it is likely that they look into the manuals and find
alternativesettings. Configuration of libraries is not clear to everyone.
>
> 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.
That is true but I came across a discussion that for several reasons a proposal to add build-time options for
authenticationmethods was not implemented. I'm trying to avoid modification of the source code if I can. I agree that I
mayhave to build a modified server if I don't find a better solution.
Regards Klaus