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

2013/4/5 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Thu, Apr 4, 2013 at 8:26 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> OK, I follow the manner of the terminology as we usually call it.
>> The attached patch just replaced things you suggested.
>
> Thanks, I have committed this, after making some changes to the
> comments and documentation. Please review the changes and let me know
> if you see any mistakes.
>
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.

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.

> 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?

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>