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