On Thu, Jun 19, 2014 at 10:21:06PM -0400, Tom Lane wrote: > Noah Misch <[email protected]> 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
