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
