Re: Spoofing as the postmaster - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: Spoofing as the postmaster |
Date | |
Msg-id | 14358.1198439548@sss.pgh.pa.us Whole thread Raw |
In response to | Re: Spoofing as the postmaster (Gregory Stark <stark@enterprisedb.com>) |
Responses |
Re: Spoofing as the postmaster
(Kurt Roeckx <kurt@roeckx.be>)
Re: Spoofing as the postmaster (Martijn van Oosterhout <kleptog@svana.org>) Re: Spoofing as the postmaster (Bruce Momjian <bruce@momjian.us>) Re: Spoofing as the postmaster (Tomasz Ostrowski <tometzky@batory.org.pl>) Re: Spoofing as the postmaster (Bruce Momjian <bruce@momjian.us>) |
List | pgsql-hackers |
Gregory Stark <stark@enterprisedb.com> writes: > Bruce summarized the problem pretty well when he said that if Postgres > is being run as a non-root user then one non-root user's "postgres" is > as good as any other non-root user's "postgres". "Problem"? What we mustn't lose sight of is that that's not a bug but a feature. It would be completely inappropriate for us as upstream to destroy that property, and my fundamental objection to what Debian has done is that they've destroyed that property at the distro level. I have no problem with the admin for a single installation putting in things that prevent there being more than one postmaster on that machine. I just say that software distribution time is not the place for such restrictions. > If you're content to take the "postgres" user as special then you could call > getsockopt(SO_PEERCRED) to verify you're really connected to a process run by > "postgres". But that isn't going to work if the postgres user could be named > something else. In that case what is it you want to verify though? This is basically the same old mutual authentication problem that SSL was designed to solve by using certificates. I don't think we have either the need or the expertise to re-invent that wheel. ISTM we have these action items: 1. Improve the code so that SSL authentication can be used across a Unix-socket connection (we can disable encryption though). 2. Improve our documentation about how to set up mutual authentication under SSL (it's a bit scattered now). 3. Recommend using mutual auth even for local connections, if a server containing sensitive data is to be run on a machine that also hosts untrusted users. As somebody noted, it's probably even better policy to not have any sensitive data on a machine that hosts untrusted users, and it wouldn't hurt for the docs to point that out; but we should have a documented solution available if you have to do it. regards, tom lane
pgsql-hackers by date: