Re: [sepgsql 2/3] Add db_schema:search permission checks

On Mon, Apr 8, 2013 at 12:28 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> Thanks. I could find two obvious wording stuffs here, please see smaller
> one of the attached patches. I didn't fixup manner to use "XXX" in source
> code comments.

Committed.

> Also, the attached function-execute-permission patch is a rebased
> version. I rethought its event name should be OAT_FUNCTION_EXECUTE,
> rather than OAT_FUNCTION_EXEC according to the manner without
> abbreviation. Other portion is same as previous ones.

Great.  This looks fine to me, committed.  I also committed your
getObjectIdentity patch, which caused some regression test output
changes.  I applied the necessary correction before committing, I
think, but please check.

>> BTW, if it were possible to set things up so that the test_sepgsql
>> script could validate the version of the sepgsql-regtest policy
>> installed, that would eliminate a certain category of errors.  I
>> notice also that the regression tests themselves seem to fail if you
>> invoke the script as contrib/sepgsql/test_sepgsql rather than
>> ./test_sepgsql, which suggests another possible pre-validation step.
>>
> Please see the test-script-fixup patch.
> I added "cd `dirname $0`" on top of the script. It makes pg_regress to
> avoid this troubles. Probably, pg_regress was unavailable to read
> sql commands to run.
>
> A problem regarding to validation of sepgsql-regtest policy module
> is originated by semodule commands that takes root privilege to
> list up installed policy modules. So, I avoided to use this command
> in the test_sepgsql script.
> However, I have an idea that does not raise script fail even if "sudo
> semodule -l" returned an error, except for a case when it can run
> correctly and the policy version is not expected one.
> How about your opinion for this check?

Not sure that's too useful.  And I don't like the idea of putting sudo
commands in a test harness script.  That seems too much like the sort
of thing bad people do.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company