Disabling trust/ident authentication configure option

On Thu, Apr 16, 2015 at 9:55 AM, Bernd Helmle <mailings@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
little knowledge of databases and especially PostgreSQL setup.

We now want to provide these kinds of users with pre-hardened packages that
make it very hard to accidentally expose their database. For this purpose
the patch allows to optionally disable the "trust" and "ident"
authentication methods. Especially the "trust" mechanism is very critical
as it might actually provide useful functionality for our user. Think of an
engineer who has to do a night shift upgrade with a customer breathing down
his neck to get the system back online. Circumventing all these
authentication configuration issues by just enabling "trust" is very easy
and looks well supported and documented.

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 access to the database server from configuring it
insecurely.

Of course, it's fine for people to make changes like this in their own
copies of PostgreSQL, but I'm not in favor of incorporating those
changes into core. I don't think there's enough general utility to
this to justify that, and more to the point, I think different people
will want different things. We haven't, for example, ever had a
request for this specific thing before.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--On 30. April 2015 08:00:23 -0400 Robert Haas <robertmhaas@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 access to the database server from configuring it
insecurely.

Sure. But I think the point is to make their engineers to think about what
they're doing. Typing in a password gives you at least a hint, that you are
probably should use something safe.

I agree that you couldn't really make that bullet proof from just this
excluded functionality, but i could imagine that this makes sense in a more
system-wide context.

Of course, it's fine for people to make changes like this in their own
copies of PostgreSQL, but I'm not in favor of incorporating those
changes into core. I don't think there's enough general utility to
this to justify that, and more to the point, I think different people
will want different things. We haven't, for example, ever had a
request for this specific thing before.

Well, i found at least one of such a proposal here:

</messages/by-id/CAN2Y=uMt7CPkxZhAUfw7SzecKdWCWsUuLmh4XPhUxKqBtdUoyA@mail.gmail.com&gt;

--
Thanks

Bernd

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 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 this is dangerous and when. Especially as it is well
documented it might seem legit to some people who are not that experienced
with postgres setup. I think this case is sufficiently generic to be
applicable to many others and to justify to at least provide the option to
work around it. Preventing such configuration errors is a usual topic in
most hardening guidelines and most commercial databases take steps to offer
more secure mechanisms to implement passwordless access or reset passwords.

Regarding passwords what you are saying is basically a "People can leave
their windows open anyways, so why bother installing door locks" kind of
argument. In my opinion the secure way to go would be to allow exactly one
defined way to access the DB without authentication / reset authentication
tokens and make this way easily recognizable / auditable. A nice addition
would be to be able to force password policies (e.g. using passwordcheck +
something like cracklib)...

So please consider to include this patch as it does not change the default
behavior but implement a simple way to comply with security policies and
actually increase security for some specific use cases.

BR,

Volker Aßmann

On Thu, Apr 30, 2015 at 2:00 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Tue, May 5, 2015 at 8:05 AM, Volker Aßmann <volker.assmann@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 this
is dangerous and when.

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? I suppose that's possible, but I really think that if you
install an *authentication method* whose name means *just trust the
other guy to be telling the truth* without thinking about the
consequences of that, it's hard to have a lot of sympathy for whatever
happens afterwards.

Besides, your patch doesn't just disable "trust". It also disables
"ident" authentication, which in some network configurations could
conceivably be more secure than password authentication. When applied
to the local machine, "ident" actually means "peer", which has an
*excellent* chance of being more secure than password authentication.
For that matter, even "trust" might be better than "password".
Anybody who can sniff the network traffic can read the password right
off of the wire. So either way, your PostgreSQL server is gonna get
hacked, but if you use password authentication, you might reveal a
password that is also used to protect access to something else that
used to be secure.

Personally, if I were going to start disabling authentication methods
at compile time, I'd start with password and md5. If you are not
using SSL, and you use password or md5 authentication, you're
basically saying, well, I'm OK with somebody reading all of the data
that I'm sending and receiving over the wire, and I'm willing to take
the risk that my passwords are easily crackable or can be read
straight off the wire using wireshark, but to send your own queries
you will have to make at least some minimal effort. If you need real
security, that is not nearly good enough. If you don't need real
security, why bother making people hassle with a password that's not
providing any real protection? There are some valid answers to that
question - e.g. if you are on a corporate WAN, you probably can't fire
somebody for blundering into an unprotected resource, but if somebody
goes to the trouble of cracking the password, even if it's weak, then
you can probably nail them.

For most users, though, I think password and md5 authentication serve
mostly to give people the illusion that they've secured the server.
The real security, if there is any, comes primarily from restricting
incoming connections via listen_addresses and/or operating system
mechanisms such as iptables and/or pg_hba.conf, and from requiring the
use of SSL. Passwords are weak sauce.

A final point to consider is: what happens when you lock yourself out
of the server, like by forgetting that password? Normally you can
recover by logging in as the postgres operating system user and then
connecting to the server using trust or peer authentication locally;
or you can make some temporary modification to pg_hba.conf to open up
trust access over the network in a carefully considered and temporary
way. But your proposal would remove that safety hatch. I guess you
could shut down the server and start up a single-user session to
change the password, but that means taking an outage. Again, if you
like that trade-off, you can patch your own copy of the source code
however you like, but that doesn't sound like something I'd want to
recommend in general.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, May 5, 2015 at 10:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Tue, May 5, 2015 at 8:05 AM, Volker Aßmann <volker.assmann@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

this

is dangerous and when.

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? I suppose that's possible, but I really think that if you
install an *authentication method* whose name means *just trust the
other guy to be telling the truth* without thinking about the
consequences of that, it's hard to have a lot of sympathy for whatever
happens afterwards.

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?" - so this at least requires to actively read about this, while any
person working in IT should have at least a rough understanding that weak
passwords are bad...

And trust is IMHO dangerous because even people who might know about the
dangers may choose to temporarily turn it on ("let me just finish this
update and I will worry about the authentication settings later") and then
forget to disable it again - aka it might actually be useful...

Besides, your patch doesn't just disable "trust". It also disables
"ident" authentication, which in some network configurations could
conceivably be more secure than password authentication. When applied
to the local machine, "ident" actually means "peer", which has an
*excellent* chance of being more secure than password authentication.
For that matter, even "trust" might be better than "password".
Anybody who can sniff the network traffic can read the password right
off of the wire. So either way, your PostgreSQL server is gonna get
hacked, but if you use password authentication, you might reveal a
password that is also used to protect access to something else that
used to be secure.

You are right, ident is not the same "ättack vector" as trust, you most
likely won't activate this by accident, but I think it is still a dangerous
mode that would be reasonable to deactivate if it's not needed.

Personally, if I were going to start disabling authentication methods
at compile time, I'd start with password and md5. If you are not
using SSL, and you use password or md5 authentication, you're
basically saying, well, I'm OK with somebody reading all of the data
that I'm sending and receiving over the wire, and I'm willing to take
the risk that my passwords are easily crackable or can be read
straight off the wire using wireshark, but to send your own queries
you will have to make at least some minimal effort. If you need real
security, that is not nearly good enough. If you don't need real
security, why bother making people hassle with a password that's not
providing any real protection? There are some valid answers to that
question - e.g. if you are on a corporate WAN, you probably can't fire
somebody for blundering into an unprotected resource, but if somebody
goes to the trouble of cracking the password, even if it's weak, then
you can probably nail them.

For most users, though, I think password and md5 authentication serve
mostly to give people the illusion that they've secured the server.
The real security, if there is any, comes primarily from restricting
incoming connections via listen_addresses and/or operating system
mechanisms such as iptables and/or pg_hba.conf, and from requiring the
use of SSL. Passwords are weak sauce.

Yes, passwords can be as bad as trust authentication or basically any other
method done implemented insecurely, so from my point of view the best
solution would be to be able to selectively enable/disable all
authentication methods to customize the package for specific environments.

Trust is in my point of view just the most immediately obvious "shoot
yourself in the foot" option and in my use case the thing that users are
actually bound to try and get wrong.

Please note that the patch does nothing by default, it just adds the option
to disable trust/ident but leaves them on in the standard configuration. I
do not want to disable "trust" by default for everyone, but it would be
great to have the option to do this without having to patch (and thus test
and verify) the PostgreSQL sources for each new release.

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 to check this in the runtime configuration.

A final point to consider is: what happens when you lock yourself out
of the server, like by forgetting that password? Normally you can
recover by logging in as the postgres operating system user and then
connecting to the server using trust or peer authentication locally;
or you can make some temporary modification to pg_hba.conf to open up
trust access over the network in a carefully considered and temporary
way. But your proposal would remove that safety hatch. I guess you
could shut down the server and start up a single-user session to
change the password, but that means taking an outage. Again, if you
like that trade-off, you can patch your own copy of the source code
however you like, but that doesn't sound like something I'd want to
recommend in general.

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.

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. Should
we only offer options that we consider to be completely secure, and no
others? If we were to follow that principle, we would completely
disable non-SSL builds, and all auth methods other than, I dunno, GSSAPI
and such. But we don't do that, because we trust that users will use
whatever is most appropriate for them. I see this patch is, in a way, a
mechanism to let system administrators choose at compile time what
options are available to DBAs at setup time. This seems a reasonable
thing to me.

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, this might be too fiddly to implement, though,
and if so I think the method proposed by this patch seems a reasonable
compromise. I've seen configure in other programs offer options such as
--disable-foo=list that lists acceptable values (or --disable-foo=help)

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 the
option to disable trust/ident but leaves them on in the standard
configuration. I do not want to disable "trust" by default for everyone,
but it would be great to have the option to do this without having to
patch (and thus test and verify) the PostgreSQL sources for each new
release.

Any new compile-time option creates a nonlinear maintenance burden.
We're going to need to test whether each option builds cleanly and
works, also in combination with other options, and on several platforms.
The authentication code is already littered with build-time
dependencies and platform-specific code. So the "it doesn't bother
anyone" argument doesn't quite work.

Actually, in this particular case, you wouldn't even need a compile-time
option. You could just make it a restart-only option.

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 to check this in the runtime
configuration.

I think people would be interested in well-thought out, generalized
hardening facilities. But that would likely include other things than
just disabling an authentication method or two. And we can't be adding
a new compile-time option as we add each one. We need a more general
approach.

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.

"peer" authentication is unfortunately not quite portable.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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, this might be too fiddly to implement, though,
and if so I think the method proposed by this patch seems a reasonable
compromise. I've seen configure in other programs offer options such as
--disable-foo=list that lists acceptable values (or --disable-foo=help)

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 footgun which would require the whole server to be stopped so
you could connect in single user mode to correct certain mistakes, which
are unfortunately all too common.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, May 6, 2015 at 3:57 PM, Andrew Dunstan <andrew@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
footgun which would require the whole server to be stopped so you could
connect in single user mode to correct certain mistakes, which are
unfortunately all too common.

Of course that's precisely what the OP wanted to do, which goes to my
point that not everybody's going to want the same thing.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 05/06/2015 04:19 PM, Robert Haas wrote:

On Wed, May 6, 2015 at 3:57 PM, Andrew Dunstan <andrew@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
footgun which would require the whole server to be stopped so you could
connect in single user mode to correct certain mistakes, which are
unfortunately all too common.

Of course that's precisely what the OP wanted to do, which goes to my
point that not everybody's going to want the same thing.

If that is indeed the proposal, then I vote no.

But he did say upthread:

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

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andrew Dunstan <andrew@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
option.

Probably the right time to make any such changes is at the same time
we add the proposed more-secure-than-MD5 password option.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 to check this in the runtime
configuration.

I think people would be interested in well-thought out, generalized
hardening facilities. But that would likely include other things than
just disabling an authentication method or two. And we can't be adding
a new compile-time option as we add each one. We need a more general
approach.

Yeah. I think one of the big use cases here is that many environments
are OK with at least ident (if not trust) but only from the local
machine. So you'd probably want to handle that somehow.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 05/06/2015 02:13 PM, Tom Lane wrote:

Andrew Dunstan <andrew@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
option.

I have seen it in the last year, actually, but only once, which even for
my personal pool represents < 1% usage. So ...

Probably the right time to make any such changes is at the same time
we add the proposed more-secure-than-MD5 password option.

+1 to kill off ident when we replace MD5, since users will need to be
beaten over the head about changes to auth methods anyway.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 and
disabling it in the code removes the need to check this in the runtime
configuration.

I think people would be interested in well-thought out, generalized
hardening facilities. But that would likely include other things than
just disabling an authentication method or two. And we can't be adding
a new compile-time option as we add each one. We need a more general
approach.

Yeah. I think one of the big use cases here is that many environments
are OK with at least ident (if not trust) but only from the local
machine. So you'd probably want to handle that somehow.

That's called 'peer', since 9.1.

- Heikki

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On May 7, 2015 12:41 AM, "Heikki Linnakangas" <hlinnaka@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 for
PostgreSQL unconditionally require to disable trust authentication and
disabling it in the code removes the need to check this in the runtime
configuration.

I think people would be interested in well-thought out, generalized
hardening facilities. But that would likely include other things than
just disabling an authentication method or two. And we can't be adding
a new compile-time option as we add each one. We need a more general
approach.

Yeah. I think one of the big use cases here is that many environments
are OK with at least ident (if not trust) but only from the local
machine. So you'd probably want to handle that somehow.

That's called 'peer', since 9.1.

There is also ident over localhost tcp. Since it only passes through the
local kernel, it can probably be considered quite secure (but requires an
extra piece of software to be installed, but that's easy). And provides a
usable option for those that can't use peer.

/Magnus

On Wed, May 6, 2015 at 4:47 PM, Alvaro Herrera <alvherre@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" might not be
secure?

Ultimately, what we offer to users is choice of a few options. Should
we only offer options that we consider to be completely secure, and no
others? If we were to follow that principle, we would completely
disable non-SSL builds, and all auth methods other than, I dunno, GSSAPI
and such. But we don't do that, because we trust that users will use
whatever is most appropriate for them. I see this patch is, in a way, a
mechanism to let system administrators choose at compile time what
options are available to DBAs at setup time. This seems a reasonable
thing to me.

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 necessarily agree with the patch as proposed. I would rather
have a comma-separated list of methods, as in:

--disable-auth=ident,peer

Something more general like that would be even better, and when reading the
comments below perhaps also the option to differentiate between local and
remote authentication. I will look into this and see if we could update the
patch to a more generic option in case people here agree that it is
worthwhile.

I would be adding additional options:

--disable-remote-auth=ident,trust
--disable-local-auth=trust

And would check that there is a warning about the password reset
restrictions in case both peer and trust (and on Windows?) are disabled.

* Josh Berkus (josh@agliodbs.com) wrote:

On 05/06/2015 02:13 PM, Tom Lane wrote:

Andrew Dunstan <andrew@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
option.

I have seen it in the last year, actually, but only once, which even for
my personal pool represents < 1% usage. So ...

Probably the right time to make any such changes is at the same time
we add the proposed more-secure-than-MD5 password option.

+1 to kill off ident when we replace MD5, since users will need to be
beaten over the head about changes to auth methods anyway.

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 network service like PG. I'd suggest ripping it out
entirely but I'm sure that'd be even less popular and Andrew does make a
good point that our single-user-mode is still so terrible that we have
to support a multi-user-mode with zero auth, to deal with certain kinds
of breakage/corruption. The fix for that is having a real single-user
mode that is usable, as has been discussed previously, but we don't seem
to be making much progress in that direction, unfortunately.

Thanks!

Stephen

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 necessarily agree with the patch as proposed.� I would rather
have a comma-separated list of methods, as in:

� � --disable-auth=ident,peer

Why don't they just apply a source code patch before compiling?
Configure seems like an odd place for this.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Thu, May 7, 2015 at 11:02 AM, Stephen Frost <sfrost@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 network service like PG.

I disagree wholeheartedly. There is such a thing as a trusted network.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers