> >> 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).

//Magnus


Tue, 13 Jul 2004 17:03:48 +0200
"Magnus Hagander" <mha@sollentuna.net>
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


13 Jul 2004 11:44:30 -0400
Robert Treat <xzilla@users.sourceforge.net>
Re: Is "trust" really a good default?
Robert Treat <xzilla@users.sourceforge.net> writes:
> 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??  

The other thing that bothers me about this proposal is that password
auth is certainly the least convenient-to-use auth method we have,
and it encourages insecure practices like coding passwords right into
access scripts.  So I'm not pleased with the idea of making it the
default.  For local-access-only installations, either IDENT or
socket-file-permissions-based access control is likely to be a much more
usable choice, but I don't think we can usefully make either of those
the default either.  So it still comes down to the DBA having to make a
conscious choice.

If what you want to do is raise the visibility of the need to make that
choice, we could do something like this:

	initdb --trust
		installs pg_hba.conf with TRUST local auth, same as now
	initdb with -W or --pwfile
		installs pg_hba.conf with MD5 local auth
	initdb with no relevant switch
		installs pg_hba.conf with REJECT local auth

thus forcing the DBA to make some choice before he can do anything.

We could also add initdb --ident to install with IDENT local auth,
which would be a cleaner solution for the distros that are currently
enforcing that policy via a patch to pg_hba.conf.sample.

I suspect however that we'd wind up reverting the whole thing before
we get out of beta, because one thing I guarantee you is there will
be lots of complaints.

The only part of this discussion that I'd really be prepared to buy into
is the part about *if* you use -W or --pwfile, then set up pg_hba.conf
with MD5 as the default auth (because that's probably what the user
wants anyway).  But otherwise I think we should leave initdb's behavior
alone.  I do not agree with trying to force people to use passwords.

			regards, tom lane

Tue, 13 Jul 2004 12:38:01 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Is "trust" really a good default? 

At this stage, I would be happy adding --ident to enable only ident, and
-W/--pwfile to enable only MD5, and allow initdb to default to full
local access (with a warning printed that package builders would at
least see).

---------------------------------------------------------------------------

Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
> > 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??  
> 
> The other thing that bothers me about this proposal is that password
> auth is certainly the least convenient-to-use auth method we have,
> and it encourages insecure practices like coding passwords right into
> access scripts.  So I'm not pleased with the idea of making it the
> default.  For local-access-only installations, either IDENT or
> socket-file-permissions-based access control is likely to be a much more
> usable choice, but I don't think we can usefully make either of those
> the default either.  So it still comes down to the DBA having to make a
> conscious choice.
> 
> If what you want to do is raise the visibility of the need to make that
> choice, we could do something like this:
> 
> 	initdb --trust
> 		installs pg_hba.conf with TRUST local auth, same as now
> 	initdb with -W or --pwfile
> 		installs pg_hba.conf with MD5 local auth
> 	initdb with no relevant switch
> 		installs pg_hba.conf with REJECT local auth
> 
> thus forcing the DBA to make some choice before he can do anything.
> 
> We could also add initdb --ident to install with IDENT local auth,
> which would be a cleaner solution for the distros that are currently
> enforcing that policy via a patch to pg_hba.conf.sample.
> 
> I suspect however that we'd wind up reverting the whole thing before
> we get out of beta, because one thing I guarantee you is there will
> be lots of complaints.
> 
> The only part of this discussion that I'd really be prepared to buy into
> is the part about *if* you use -W or --pwfile, then set up pg_hba.conf
> with MD5 as the default auth (because that's probably what the user
> wants anyway).  But otherwise I think we should leave initdb's behavior
> alone.  I do not agree with trying to force people to use passwords.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tue, 13 Jul 2004 12:46:32 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Is "trust" really a good default?