"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> "Marko Kreen" <markokr@gmail.com> writes:
>> (FYI - Debian already puts unix socket to directory writable
>> only to postgres user, so they dont have the problem. Maybe
>> we should encourage distros to move away from /tmp?)
>
> No, we shouldn't, and if I had any authority over them I would make
> Debian stop doing that. It amounts to a unilateral distro-specific
> change in the protocol, and I think it makes things *less* secure,
> because any clients who are expecting the socket to be in /tmp will be
> easy pickings for a spoofer. Debian cannot hope to prevent that
> scenario, because there are non-libpq-based client implementations.
I don't understand this point of view. /tmp is there for users to play with.
If you build Postgres as a user and run it from your home directory then you
certainly can use /tmp or your home directory to communicate. But if Postgres
is provided by the OS then it can't ignore the proper places dedicated to this
purpose.
Using /tmp for a shared system resource opens the door to serious problems
such as the current issue. Also consider denial-of-service attacks by any user
creating sockets in the way of Postgres.
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". If you want to authenticate from to
another user on the same machine you have to have some kind of credential
which sets you apart.
I actually think it's quite wrong of a shared resource to not be installed to
run as root. It should cause problems like this in many places. Basically if
you were never root then you can never really prove you're not an spoof.
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?
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training!