* Don't enable "trust" auth (i.e. any OS user as any DB user) - that's rarely what you want on a multi-user machine.
* "peer" auth (OS user == DB user name) is typically the way to go in most cases - you can lock down the DB user further with GRANT privileges as required.
I use a peer map=X configuration where my application user(s) (which my app binaries run under) are mapped to DB user names. Those DB users have CONNECT privs on their own DBs (only).
So I've got two questions. One is whether there are any downsides to using sockets, or any "gotchas" to be aware of. The second is whether there is anything to do to increase the security of sockets? (e.g., analagous to encrypting localhost conenctions with SSL?) From the little I saw, it sounds like sockets are "just inherently secure," but wanted to confirm that or get another opinion!
localhost is plenty secure, only root can sniff it, and root can su to postgres and be in full ownership of your server anyways, so if you consider root a security risk, well, there's no cure for that.
unix domain sockets are quite secure too. they might be slightly faster than tcp/ip via localhost, but its probably not enough to matter.
-- john r pierce 37N 122W somewhere on the middle of the left coast
