Thread: 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(-)
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