Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension
Date
Msg-id 4551.1431620575@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Add pg_audit, an auditing extension  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> Another thing that looks not amazingly well-thought-out about that
>> regression test is that it creates a superuser role with a known name
>> (and no password, not that adding a password would make it better).

> We create a lot of roles in other tests too; the foreign_data test is
> the only one that create a superuser role.  While working on the tests
> for the DDL deparse thing, I had to create a script with a list of roles
> that all the tests use, and it's pretty amazing.  I remember thinking at
> the time that it'd be better to initialize a number of standard roles in
> an initial step, and have them be used consistently in the tests that
> require them, rather than having create/drop everywhere.

It would definitely be better if the names were less randomly chosen and
hence less likely to conflict with existing role names in an installation.
I'm not sure why we don't insist that they should all start with "regress"
or similar, for instance.

But what I'm on about at the moment is that I think creating new
superusers is a bad idea from a security standpoint.  It seems quite
unlikely that we *have* to do that for testing purposes.

Also, I notice that the pg_audit test fails to drop the roles it
created, even if it reaches the end successfully.  That's just bad.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: upper planner path-ification
Next
From: Andrew Dunstan
Date:
Subject: Re: trust authentication behavior