Thread: pgsql: Let installcheck-world pass against a server requiring a passwor

pgsql: Let installcheck-world pass against a server requiring a passwor

From
Noah Misch
Date:
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(-)


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


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