On Mon, Apr 8, 2013 at 12:28 PM, Kohei KaiGai <kai...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
