* Bruce Momjian <[EMAIL PROTECTED]> [080104 13:00]: > > Actually, if you just commit that patch *without* pg_hba modifications, > > it still solves the problem stated, no? Because the client can be > > configured to require ssl and to require server certificate validation, > > and that's the hole we're trying to plug here... > > Yes, it would plug the hole without fully implementing SSL control on > local sockets. However, the hole is already plugged by using directory > permissions so I question the need for a partial solution at this point > in 8.3.
Yet we have respected people warning us that the *only* place we can have the socket is /tmp, because that's where everybody (for varying definitions of everybody) looks. Moving the socket from /tmp actually makes the problem of a spoofed postmaster bigger. If you have a scheme to "move" or protect the unix socket, make sure you still provide the one in /tmp. A simple test looks like the /tmp/.s.PGSQL.XXXX can be a symlink the socket in the protected dir, so it may be enough for concerned admins to create this symlink (or the actual socket with correct owner/permissions) on system startup, preventing an "outsider" from taking this file before postgresql (and make sure that no tmpwatch or anything removes it again). But if PostgreSQL is started before your "untrusted user processes", then your untrusted user processes should never get the chance to spoof the server unless they get to mv/delete the postgres-user owned socket in /tmp, in which case, you've got larger problems to worry about... a. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature