From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Pg Docs <pgsql-docs(at)lists(dot)postgresql(dot)org> |
Subject: | Tightening the trust auth advice |
Date: | 2023-01-12 09:32:29 |
Message-ID: | CABUevEwtFLs03WfMtq8XOjANL7Su1z6v5pHMJNZnSvV9zEd_XA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
The page at https://www.postgresql.org/docs/current/auth-trust.html goes
through some length to explain why Trust is sometimes a good idea.
Is it really though? And in particular, aren't there better choices?
As a first step, I think we should put a <warning> box on the page
explicitly saying that that trust, unless limited in pg_hba, will allow any
user to become superuser which allows them to bypass all other security
restrictions.
Second, we're kind of going out of our way to recommend setting unix socket
permissions etc -- in those cases, wouldn't it in almost every case just be
better for the user to use "peer" auth instead of trust, and we should
recommend them to use that instead? Is it really any less appropriate
and/or convenient? (It was listed as appropriate back in 2001
in 6f0f5bf2fbe, but the world has changed a bit in 20+ years..)
And finally, the sentence "It is seldom reasonable to use trust for any
TCP/IP connections other than those from localhost (127.0.0.1)." should
probably be amended with an ", and only reasonable for localhost if you
trust every single user on the host"?
Thoughts? I'll be happy to work up a patch if there's agreement on the
general idea.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2023-01-12 14:43:57 | Re: The documentation for storage type 'plain' actually allows single byte header |
Previous Message | PG Doc comments form | 2023-01-10 15:53:10 | The documentation for storage type 'plain' actually allows single byte header |