Magnus Hagander wrote:
Certainly, I'm not saying it shuold change (I've given that up by
now). But the difference would be that if you used -W with initdb, it
would change the default *for that installation*.
Initdb-with-no-parameters would stay the same to keep people who
don't know about
Peter Eisentraut [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
Certainly, I'm not saying it shuold change (I've given that up by
now). But the difference would be that if you used -W with initdb, it
would change the default *for that installation*.
The fallacy with this line of thought is
Tom Lane wrote:
I don't really see a problem with doing it that way. People who want
to use -W are presumably worried about the security of their local
system, otherwise they would just fire up the postmaster and set a
password later.
No, that is exactly what I don't agree with. People
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
There are of course some questions about how to document this
effectively, so that it doesn't create more confusion than it avoids.
Yes, that is another thing I'm afraid of.
Yeah, if you look up-thread you'll find me expressing the
Magnus Hagander wrote:
not to mention the
more basic problem that the comments will now be wrong.
That, however, it is correct :-( Sloppy.
How about a text along the line of:
CAUTION: Configuring the system for trust authentication
allows any
local user to connect using any
No, but none of the others are better. See previous discussions in
the archives. I don't think the situation has changed any
since the
last time we hashed this out.
If they supply a password to initdb, shouldn't we then require a
password in pg_hba.conf.
This is further to my
IMO, forcing su password at initdb time (allowing blank
password with
a very stern warning) and bumping localhost to auth is the
right way
to go.
This isn't happening for a number of reasons, the most
obvious being that we cannot require initdb to be run
interactively. (That
It has probably be said before, but new users need to be able
to get up and running on their *development* system quickly.
Throwing new users for a loop with the password configuration
issues would be a problem.
This is exactly the argument that was thrown out when people wanted to
be
Magnus Hagander wrote:
This is the very reason --pwfile was added. It's not just a win32
fix, it's a any packager that needs to run without interactivity
fix. Yes, you can stick a blank password in there, but again, this is
a choice and not a default in that case.
No, that's not what it was
Magnus Hagander [EMAIL PROTECTED] writes:
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
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
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.
Robert Treat [EMAIL PROTECTED] 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
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).
---
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
Magnus Hagander wrote:
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
Magnus Hagander [EMAIL PROTECTED] writes:
The only part of this discussion that I'd really be prepared=20
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).
Ok. Here is a patch
The only part of this discussion that I'd really be prepared=20
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).
Ok. Here is a patch that does this.
... and rather severely
Bruce Momjian [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
Might still be worth adding --ident as a parameter anyway, but in that
case only to help the distros that need it. Or not, because they already
have a way to deal with it.
I think --ident would be very helpful, and we know with
Magnus Hagander wrote:
The only part of this discussion that I'd really be prepared=20
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).
Ok. Here is a patch that does
Magnus Hagander wrote:
not to mention the
more basic problem that the comments will now be wrong.
That, however, it is correct :-( Sloppy.
How about a text along the line of:
CAUTION: Configuring the system for trust authentication allows any
local user to connect using any PostgreSQL
On Tue, 2004-07-13 at 22:27, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I think --ident would be very helpful, and we know with OS's support
ident too.
If we're going to be doing sed-like substitutions on pg_hba.conf.sample,
then we really really wanna discourage distros from
On Monday 12 July 2004 17:10, Merlin Moncure wrote:
IMO, forcing su password at initdb time (allowing blank password with a
very stern warning) and bumping localhost to auth is the right way to
go. As far as RPM's, etc. I don't think RPM considerations should be
driving security concerns.
Magnus Hagander [EMAIL PROTECTED] writes:
Is it really such a good idea to have trust authentication enabled for
localhost (TCP/IP and Unix sockets) by default?
No, but none of the others are better. See previous discussions in the
archives. I don't think the situation has changed any since
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Is it really such a good idea to have trust authentication enabled for
localhost (TCP/IP and Unix sockets) by default?
No, but none of the others are better. See previous discussions in the
archives. I don't think the situation
Bruce Momjian [EMAIL PROTECTED] writes:
If they supply a password to initdb, shouldn't we then require a
password in pg_hba.conf.
We could, but I'm a bit disturbed about the issues of documenting two
fundamentally different out-of-the-box behaviors. The ensuing confusion
might be worse than
tom lane wrote:
The bottom line to my mind is that if there were a one-size-fits-all
authentication solution, we'd not have so many to choose from. I
don't
think we are doing DBAs any service by pretending that they might not
need to think about their choice of auth method. I could make a
Merlin Moncure [EMAIL PROTECTED] writes:
IMO, forcing su password at initdb time (allowing blank password with a
very stern warning) and bumping localhost to auth is the right way to
go.
This isn't happening for a number of reasons, the most obvious being
that we cannot require initdb to be
It has probably be said before, but new users need
to be able to get up and running on their *development*
system quickly. Throwing new users for a loop with
the password configuration issues would be a problem.
Most people would put up a test server first anyway
in order to check things out and
No, but none of the others are better. See previous discussions in the
archives. I don't think the situation has changed any since the last
time we hashed this out.
I'll chime in from the phpPgAdmin point of view. The thing with
phpPgAdmin is that it breaks the 'localhost' access is safe rule
No, but none of the others are better. See previous discussions in the
archives. I don't think the situation has changed any since the last
time we hashed this out.
If they supply a password to initdb, shouldn't we then require a
password in pg_hba.conf.
This is further to my previous suggestion
31 matches
Mail list logo
