pgsql: Let installcheck-world pass against a server requiring a passwor
Let installcheck-world pass against a server requiring a password.
Give passwords to each user created in support of an ECPG connection
test case. Use SET SESSION AUTHORIZATION, not a fresh connection, to
reduce privileges during a dblink test case.
To test against such a server, both the "make installcheck-world"
environment and the postmaster environment must provide the default
user's password; $PGPASSFILE is the principal way to do so. (The
postmaster environment needs it for dblink and postgres_fdw tests.)
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/c82725edfa1aec1cad940b15b6e22ee3dbd57f20
Modified Files
--------------
contrib/dblink/expected/dblink.out | 9 +--
contrib/dblink/sql/dblink.sql | 9 +--
src/interfaces/ecpg/test/connect/test5.pgc | 18 +++--
src/interfaces/ecpg/test/expected/connect-test5.c | 82 +++++++++++---------
.../ecpg/test/expected/connect-test5.stderr | 18 +++--
5 files changed, 75 insertions(+), 61 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Noah Misch <noah@leadboat.com> writes:
Let installcheck-world pass against a server requiring a password.
Give passwords to each user created in support of an ECPG connection
test case. Use SET SESSION AUTHORIZATION, not a fresh connection, to
reduce privileges during a dblink test case.
Hm ... is this reasonably secure? It seems like it's creating user
accounts with well-known passwords. The accounts might not be there
for long, but still, I'm not sure I'd care to run this against an
installed server on a machine with hostile users present.
(The problem might have been there even before your patch, but that
doesn't mean it's not a problem.)
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On Thu, Jun 19, 2014 at 10:21:06PM -0400, Tom Lane wrote:
Noah Misch <noah@leadboat.com> writes:
Let installcheck-world pass against a server requiring a password.
Give passwords to each user created in support of an ECPG connection
test case. Use SET SESSION AUTHORIZATION, not a fresh connection, to
reduce privileges during a dblink test case.Hm ... is this reasonably secure? It seems like it's creating user
accounts with well-known passwords. The accounts might not be there
for long, but still, I'm not sure I'd care to run this against an
installed server on a machine with hostile users present.
Neither would I; I would stick with a secured Unix socket and not mess with
authentication methods. Still, using md5 with a default socket is a large
security improvement compared to using trust authentication with a default
socket. In place of giving superuser rights to anyone who shows up, you've
given a plain account.
(The problem might have been there even before your patch, but that
doesn't mean it's not a problem.)
One simple fix would be to make those users NOLOGIN. The expected output
would then look for 'FATAL: role "connectdb" is not permitted to log in' and
similar, which appearance shows that authentication did succeed. That loses
coverage of the later steps of non-superuser backend initialization, but
perhaps losing that is the lesser of these evils?
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers