Josh Berkus j...@agliodbs.com writes:
So from my perspective anything which requires going off standard
PostgreSQL packages, and encourages users to go off standard PostgreSQL
packages, is a actually a fairly high cost even if the code is
non-invasive.
Agreed.
I would be more open to a GUC
Volker,
I likely just viewed this too much through a security lens - you see a
possible attack scenario, a way to turn it off, and only minor
downsides, so just go for it - but this is not how you can work in a
huge open source project. I guess as a developer you would have to take
many
On Wed, May 20, 2015 at 5:21 PM, Robert Haas robertmh...@gmail.com wrote:
Please don't be discouraged here. Contributing to the PostgreSQL
community can be frustrating when you don't get what you want, and
even though I have been a member of this community for about 7 years
now and am a
On Tue, May 19, 2015 at 1:53 AM, Robert Haas robertmh...@gmail.com wrote:
On May 18, 2015, at 3:32 PM, Volker Aßmann volker.assm...@gmail.com
wrote:
I know these measures won't protect against an experienced attacker who
gains root access, but hope it slows them down sufficiently so the
On 05/20/2015 01:20 AM, Volker Aßmann wrote:
So, in the interests of trying to get you to understand why your
proposal met with a negative response, and to improve future proposals:
You don't seem to have much trust in your other authentication
mechanisms and seem to know our environment quite
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Josh Berkus wrote:
As such, proposals are more likely to be successful if the proposer can
show how they apply to a general use case, or adapt them so that they
are useful to a large number of our users. This means that this works
in our
Andres Freund wrote:
On 2015-05-20 15:42:23 -0400, Stephen Frost wrote:
So the first thing to establish is other than Volker himself, who are
we helping here?
I don't agree with this either. Providing a bypass all authentication
configuration option really isn't a good thing. Why
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
I don't agree with this either. Providing a bypass all authentication
configuration option really isn't a good thing. Why don't packagers use
our default pg_hba.conf? Because it only makes sense in a
Stephen Frost sfr...@snowman.net writes:
I don't agree with this either. Providing a bypass all authentication
configuration option really isn't a good thing. Why don't packagers use
our default pg_hba.conf? Because it only makes sense in a development
type of environment. I'd argue the
On 2015-05-20 15:42:23 -0400, Stephen Frost wrote:
So the first thing to establish is other than Volker himself, who are
we helping here?
I don't agree with this either. Providing a bypass all authentication
configuration option really isn't a good thing. Why don't packagers use
our
Josh Berkus wrote:
As such, proposals are more likely to be successful if the proposer can
show how they apply to a general use case, or adapt them so that they
are useful to a large number of our users. This means that this works
in our environment which has conditions X, Y, and Z is not an
On 05/20/2015 11:10 AM, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Josh Berkus wrote:
As such, proposals are more likely to be successful if the proposer can
show how they apply to a general use case, or adapt them so that they
are useful to a large number of our users.
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Josh Berkus wrote:
As such, proposals are more likely to be successful if the proposer can
show how they apply to a general use case, or adapt them so that they
are useful to a large number of our users. This means that this works
in
* Josh Berkus (j...@agliodbs.com) wrote:
On 05/20/2015 11:10 AM, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
The proposal here is to have a configure argument that disables
arbitrary auth mechanisms. How is that specific to a particular
environment?
I think
* Andres Freund (and...@anarazel.de) wrote:
On 2015-05-20 19:46:12 -0400, Stephen Frost wrote:
In other words, I agree with you that we can't simply get rid of 'trust'
without having another solution. I *do* believe that a real single-user
mode that is only available to the owner of the
On Wed, May 20, 2015 at 07:03:26PM -0400, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Michael Banck wrote:
The other set of users I could think of are those who, for whatever
reason, tend to always compile PostgreSQL from source for their
company/organization. Maybe
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Michael Banck wrote:
The other set of users I could think of are those who, for whatever
reason, tend to always compile PostgreSQL from source for their
company/organization. Maybe they have internal rules that requires a
custom installation
Andres,
* Andres Freund (and...@anarazel.de) wrote:
On 2015-05-20 15:42:23 -0400, Stephen Frost wrote:
So the first thing to establish is other than Volker himself, who are
we helping here?
I don't agree with this either. Providing a bypass all authentication
configuration option
On 2015-05-20 19:46:12 -0400, Stephen Frost wrote:
In other words, I agree with you that we can't simply get rid of 'trust'
without having another solution. I *do* believe that a real single-user
mode that is only available to the owner of the cluster would go a long
way towards this goal.
I
On 5/20/15 7:19 PM, Stephen Frost wrote:
* Andres Freund (and...@anarazel.de) wrote:
On 2015-05-20 19:46:12 -0400, Stephen Frost wrote:
In other words, I agree with you that we can't simply get rid of 'trust'
without having another solution. I*do* believe that a real single-user
mode that
On Wed, May 20, 2015 at 02:10:30PM -0400, Tom Lane wrote:
One reason why it would not be, if it's a build-time decision,
is that it's quite unlikely that any popular packagers would build
that way. So this would only be applicable to custom-built binaries,
which is a pretty small class of
Michael Banck wrote:
On Wed, May 20, 2015 at 02:10:30PM -0400, Tom Lane wrote:
One reason why it would not be, if it's a build-time decision,
is that it's quite unlikely that any popular packagers would build
that way. So this would only be applicable to custom-built binaries,
which is a
* Michael Banck (mba...@gmx.net) wrote:
On Wed, May 20, 2015 at 07:03:26PM -0400, Tom Lane wrote:
I think Andres' point about trust being an essential disaster recovery
mode is something to consider, as well. That puts pretty strict limits
on what would be a credible replacement.
Then
On Wed, May 20, 2015 at 7:09 PM, Michael Banck mba...@gmx.net wrote:
I think Andres' point about trust being an essential disaster recovery
mode is something to consider, as well. That puts pretty strict limits
on what would be a credible replacement.
Then let's rename it from `trust' to
On Wed, May 20, 2015 at 4:20 AM, Volker Aßmann volker.assm...@gmail.com wrote:
On Tue, May 19, 2015 at 1:53 AM, Robert Haas robertmh...@gmail.com wrote:
On May 18, 2015, at 3:32 PM, Volker Aßmann volker.assm...@gmail.com
wrote:
I know these measures won't protect against an experienced
On 5/17/15 10:58 PM, Josh Berkus wrote:
The goal here was stated to preventing authentication misconfiguration
by shortsighted admins who have superuser access and the ability to
change pg_hba.conf. This is tantamount to giving someone a gun and
bullets, but expecting duct tape across the
On 05/18/2015 11:36 AM, Jim Nasby wrote:
On 5/17/15 10:58 PM, Josh Berkus wrote:
The goal here was stated to preventing authentication misconfiguration
by shortsighted admins who have superuser access and the ability to
change pg_hba.conf. This is tantamount to giving someone a gun and
On 05/17/2015 08:58 PM, Josh Berkus wrote:
You've added exactly one additional step in their way, and not a
particularly difficult one. It simply doesn't solve the problem you're
trying to solve, which is unsurprising, because technology has never
been able to solve the problem of
On 05/18/2015 08:36 AM, Jim Nasby wrote:
On 5/17/15 10:58 PM, Josh Berkus wrote:
The goal here was stated to preventing authentication misconfiguration
by shortsighted admins who have superuser access and the ability to
change pg_hba.conf. This is tantamount to giving someone a gun and
On Mon, May 18, 2015 at 5:58 AM, Josh Berkus j...@agliodbs.com wrote:
Let's say we offered a compile-time option, and then someone built a
package postgresql-9.6-secureauth.deb. So, your lazy admin is having
trouble debugging an auth problem and wants to set trust. But they
can't. So they
On Mon, May 18, 2015 at 09:32:23PM +0200, Volker Aßmann wrote:
That's what we are currently doing with the patch Bernd posted at the
beginning
of this thread. But we thought we might post the patch for consideration here
as the use case might be sufficiently general that it may be of use to
Bruce Momjian wrote:
On Mon, May 18, 2015 at 09:32:23PM +0200, Volker Aßmann wrote:
But I like the more general approach proposed by Alvaro, so in case this
patch
would have a chance to not be immediately rejected, I would try to implement
the more generic approach. I would also include
On Mon, May 18, 2015 at 05:00:41PM -0300, Alvaro Herrera wrote:
Bruce Momjian wrote:
On Mon, May 18, 2015 at 09:32:23PM +0200, Volker Aßmann wrote:
But I like the more general approach proposed by Alvaro, so in case this
patch
would have a chance to not be immediately rejected, I
On May 18, 2015, at 3:32 PM, Volker Aßmann volker.assm...@gmail.com wrote:
I know these measures won't protect against an experienced attacker who gains
root access, but hope it slows them down sufficiently so the admins may have
a chance to detect the attack.
It won't.
...Robert
--
Sent
On Wed, May 13, 2015 at 2:18 PM, Robert Haas robertmh...@gmail.com
mailto:robertmh...@gmail.com wrote:
All of this is fairly far afield from the original topic of this
thread, which was whether a configure option disabling trust + ident
authentication would be a good idea. I
Yes, I'd like to know if Alvaros suggestion would in deed achieve consensus
(possibly with Andrews addition). It looks like the most general solution
but might be some work using autoconf ...
Best regards,
Volker
On Wed, May 13, 2015 at 2:18 PM, Robert Haas robertmh...@gmail.com wrote:
On
On Mon, May 11, 2015 at 10:00 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, May 7, 2015 at 4:57 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, May 7, 2015 at 11:02 AM, Stephen Frost sfr...@snowman.net
wrote:
I realize it's not
On Wed, May 13, 2015 at 8:01 AM, Volker Aßmann volker.assm...@gmail.com wrote:
Even in this case it still means that any breach in any of the network
services running on your application server would immediately own your
database, or at least everything your application can access. This applies
On Thu, May 7, 2015 at 4:57 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, May 7, 2015 at 11:02 AM, Stephen Frost sfr...@snowman.net wrote:
I realize it's not going to be popular, but I'd love to have 'trust'
only allowed if a command-line
--On 6. Mai 2015 16:28:43 -0400 Andrew Dunstan and...@dunslane.net wrote:
Single user sessions would work, but the peer authentication is also
still available and should be the preferred method to reset passwords
when trust is disabled, so this should not be an issue.
(Personally I
On Wed, May 6, 2015 at 4:47 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Robert Haas wrote:
I frankly find that a bit difficult to swallow. You think that
everyone knows that bad passwords are a problem, but some people might
not realize that an authentication method called trust
On Thu, May 7, 2015 at 11:53:21AM +0200, Volker Aßmann wrote:
Yes in fact, it would be a way for organizations distributing their own
PostgreSQL packages to enforce authentication restrictions within the package
instead of having to educate all users about the options.
I don't
On Thu, May 7, 2015 at 11:02 AM, Stephen Frost sfr...@snowman.net wrote:
I realize it's not going to be popular, but I'd love to have 'trust'
only allowed if a command-line option is passed to the postmaster or
something along those lines. It's really got no business being an
option for a
* Robert Haas (robertmh...@gmail.com) wrote:
On Thu, May 7, 2015 at 11:02 AM, Stephen Frost sfr...@snowman.net wrote:
I realize it's not going to be popular, but I'd love to have 'trust'
only allowed if a command-line option is passed to the postmaster or
something along those lines. It's
* Josh Berkus (j...@agliodbs.com) wrote:
On 05/06/2015 02:13 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
(Personally I think there's a very good case for completely ripping out
RFC1413 ident auth. I've not seen it used in a great long while, and
it's always been a
On May 7, 2015 12:41 AM, Heikki Linnakangas hlinn...@iki.fi wrote:
On 05/07/2015 01:32 AM, Jim Nasby wrote:
On 5/6/15 12:56 PM, Peter Eisentraut wrote:
I think this is a sufficiently general requirement to warrant including
an option to disable this, as most hardening guides I have seen
On Tue, May 5, 2015 at 10:39 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 5, 2015 at 8:05 AM, Volker Aßmann volker.assm...@gmail.com
wrote:
Changing the password to something simple is immediately obvious as a
security flaw for most people who may come across database
Robert Haas wrote:
I frankly find that a bit difficult to swallow. You think that
everyone knows that bad passwords are a problem, but some people might
not realize that an authentication method called trust might not be
secure?
Ultimately, what we offer to users is choice of a few options.
On 05/06/2015 02:13 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
(Personally I think there's a very good case for completely ripping out
RFC1413 ident auth. I've not seen it used in a great long while, and
it's always been a security risk.)
FWIW, I agree with that --- or
On 5/6/15 12:56 PM, Peter Eisentraut wrote:
I think this is a sufficiently general requirement to warrant including
an option to disable this, as most hardening guides I have seen for
PostgreSQL unconditionally require to disable trust authentication and
disabling it in the code removes the need
On 05/07/2015 01:32 AM, Jim Nasby wrote:
On 5/6/15 12:56 PM, Peter Eisentraut wrote:
I think this is a sufficiently general requirement to warrant including
an option to disable this, as most hardening guides I have seen for
PostgreSQL unconditionally require to disable trust authentication
On 05/06/2015 04:19 PM, Robert Haas wrote:
On Wed, May 6, 2015 at 3:57 PM, Andrew Dunstan and...@dunslane.net wrote:
I don't necessarily object to this idea, but I do think we need to ensure
that we don't allow both trust and peer to be disabled (which means on
Windows you would not be able to
Andrew Dunstan and...@dunslane.net writes:
(Personally I think there's a very good case for completely ripping out
RFC1413 ident auth. I've not seen it used in a great long while, and
it's always been a security risk.)
FWIW, I agree with that --- or at least making it a not-built-by-default
On Wed, May 6, 2015 at 3:57 PM, Andrew Dunstan and...@dunslane.net wrote:
I don't necessarily object to this idea, but I do think we need to ensure
that we don't allow both trust and peer to be disabled (which means on
Windows you would not be able to disable trust). Otherwise this becomes a
On 05/06/2015 10:47 AM, Alvaro Herrera wrote:
I don't necessarily agree with the patch as proposed. I would rather
have a comma-separated list of methods, as in:
--disable-auth=ident,peer
which lets you choose what to disable without hardcoded choices. Due to
the nature of autoconf,
On 5/6/15 6:02 AM, Volker Aßmann wrote:
Well trust actually does not sound that dangerous in case you only
take a quick glance at the documentation - trust PostgreSQL to do the
right thing?
Hah, we could rename it to wideopen.
Please note that the patch does nothing by default, it just adds
Hello,
I am the one who suggested the patch to Credativ, so let me explain my
reasoning.
It is clear that it is basically impossible to get perfect security but
this patch would help to solve one small but for our use case quite
dangerous issue. Changing the password to something simple is
On Tue, May 5, 2015 at 8:05 AM, Volker Aßmann volker.assm...@gmail.com wrote:
Changing the password to something simple is immediately obvious as a
security flaw for most people who may come across database configurations,
but for the TRUST mode you actually need to know some background on why
--On 30. April 2015 08:00:23 -0400 Robert Haas robertmh...@gmail.com
wrote:
But... the user could use password authentication with the password
set to x and that would be insecure, too, yet not prevented by any
of this. I think it's pretty hard to prevent someone who has
filesystem-level
On Thu, Apr 16, 2015 at 9:55 AM, Bernd Helmle maili...@oopsware.de wrote:
PostgreSQL is deployed as part of a larger technical solution (e.g. a
Telecommunication system) and a field engineer has to install/upgrade this
solution. The engineer is a specialist in the Telco domain and has only
We have a customer using a patch to harden their PostgreSQL installation
(see attached) they would like to contribute. This patch adds the ability
to disable trust and ident authentication at compile time via configure
options, thus making it impossible to use these authentication methods for
61 matches
Mail list logo
