"Tom Lane" <[EMAIL PROTECTED]> writes: > "Marko Kreen" <[EMAIL PROTECTED]> 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's PostgreSQL training! ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
