> -----Ursprüngliche Nachricht----- > Von: Tom Lane <t...@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 it with 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 address ranges etc. A few people have access to this and it is likely that they look into the manuals and find alternative settings. 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 authentication methods was not implemented. I'm trying to avoid modification of the source code if I can. I agree that I may have to build a modified server if I don't find a better solution. Regards Klaus
