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 expressin
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 m
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 t
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 abou
On Wed, 2004-07-14 at 05:08, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > ...
> > The point of this explanation is that as Debian maintainer I would have
> > to disable any procedures that attempt to edit these conffiles, or at
> > least ensure that their operation is under pack
> 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
Oliver Elphick <[EMAIL PROTECTED]> writes:
> ...
> The point of this explanation is that as Debian maintainer I would have
> to disable any procedures that attempt to edit these conffiles, or at
> least ensure that their operation is under package control and produce
> only the effects that I desir
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.
Robert Treat wrote:
> > Woh, I didn't think we agreed that the default would change from
> > 'trust', only that we would now emit a warning and allow other
> > authentication methods to be specified at initdb time.
> >
>
> I sure hope not (and that was my understanding as well)
>
> Incidentally
On Tue, 2004-07-13 at 17:44, Bruce Momjian wrote:
> 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 "tr
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 dis
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 P
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.
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
>>> 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.
>
>...
"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. H
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
>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.
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).
---
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 t
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 --pwf
> >> 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
"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 ad
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
> 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
> > 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
> >>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 i
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
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 t
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
"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
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
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:
> "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 th
"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
Is it really such a good idea to have "trust" authentication enabled for
localhost (TCP/IP and Unix sockets) by default? Since this pretty much
means that anybody with shell access on the server (which depending on
the situation can be only dba people, or a whole lot of other people as
well) can do
36 matches
Mail list logo
