Re: Is "trust" really a good default?

On Tue, 2004-07-13 at 11:03, Magnus Hagander wrote:
> > >> This isn't happening for a number of reasons, the most
> > obvious being
> > >> that we cannot require initdb to be run interactively.
> > (That stern
> > >> warning will not impress /dev/null.)
> >
> > > This is the very reason --pwfile was added.
> >
> > No, that does not address the objection in the least. That
> > simply allows a level of indirection. There still has to be
> > user interaction going on somewhere to supply the password.
>
> Right. I realised that after posting.
>
> I still think it would be a good move to add a switch you have to
> explicitly put in there to make it use "trust" auth by default. This can
> spit out some warnings, which will of course be ignored by RPM and such
> packagers. But for those installs the package creator made the
> decisions, and we will still get most of the
> install-from-source-but-don't-know-about-the-switches people.
>
> It would, of course, be better if the RPMs could do this as well. Don'tk
> now how they work, though, but I assume this is the part that has been
> discussed before by people who do.
>
> Or we could initdb with requiring password, and just refuse logins with
> blank passwords. That way you get a system that can be installed, but
> you cannot actually connect to it until you have set a password. We'd
> need to supply a tool that could change the password without connecting
> (since you can't connect with no password, catch-22) but that should be
> fairly straightforward with a standalone backend, right?
>
>
>
> For reference, does anybody know how other databases do it? Like MySQL
> or Oracle (which both run on RedHat, which should mean RPMs, right?) I
> know MSSQL refuses to install with blank passwords these days (didn't
> use to be that way, no, which is why there are still a lot of
> installations out there with blank sa passwords).
>

I am sure Chris would back me up on saying that the inability to
authenticate a database connection is the #1 support problem on the
phppgadmin mailing lists.... and you want to make this harder for
people??

I think we are obliged to provide security mechanisms that people can
use, and to make sure our software is a not a conduit of exploits for
the systems we're installed on, but forcing people to deploy the
software in a fasion that we deem acceptable for production use goes
above and beyond what we should be doing.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL