On Jun 23, 2007, at 11:03 AM, Magnus Hagander wrote:
>
>> I would also argue that trust auth is not such an evil option that we
>> mustn't allow it to be the default. On a single-user machine it's
>> actually perfectly sane, seeing that we don't allow TCP connections
>> by default.
>
> Is there really such a thing as a single-user machine running
> PostgreSQL? Maybe single "human user", but if you're not running some
> other services on it (webserver, mailserver, whatever) it's not very
> likely to be running pg, I think.
My laptop and dev boxes are all single user (and all do trust
on unix sockets).
I have several webserver boxes that use local postgresql
installations. Again, trust works just fine for that. There's
no security issue unless someone has compromised the
box (probably via the webapp), and if they've done that
they already have the keys to the castle. Mailserver, ditto.
We deploy CRM systems, running on dedicated boxes,
to customers. While they tend to get configured with
md5 access, just because it's tidy and easy to explain
to IT security folks, they'd actually be just as secure with
trust auth.
> Out of curiosity, how do other databases deal with this? The only one
> I've been installing recently is MSSQL which basically lets you chose
> between SSPI
> (ident-sameuser-over-sockets-and-kerberos-over-network-equivalent) or
> password (md5 equivalent, AFAIK). It does *not* let you use empty
> passwords, which is what would be equivalent with our "trust".
But that's not an installation from source. That's a packaged
installation, provided by the distribution owner. It's much more
comparable to, say, a Debian package.
MySQL installs with an empty root password for access from
localhost or the machines own IP address. It also installs an
account with network access to any database beginning with
"test" and possibly some more ill-defined accounts with local
access.
Part of the suggested post-install process for mysql involves
deleting some of those accounts and setting password for root.
Cheers, Steve