Thanks for your checking.

I doubt of whether security policy module for this regression test is not
installed on your test environment.
Could you try ./test_sepgsql after:
  $ make -f /usr/share/selinux/devel/Makefile clean
  $ make -f /usr/share/selinux/devel/Makefile
  $ sudo semodule -i sepgsql-regtest
  $ sudo semodule -l | grep sepgsql-regtest
  sepgsql-regtest 1.05

I expect the installed sepgsql-regtest should be 1.05.

This patch contains updates towards the security policy that adds
special rule to assign special default security label on system
columns, so regression test will fail if previous policy was loaded.

It might ought to be checked within ./test_sepgsql script, however,
it takes superuser privilege to run semodule -l even though it lists
all the modules without any modification...

Thanks,

2013/3/28 Robert Haas <robertmh...@gmail.com>:
> On Wed, Mar 27, 2013 at 8:41 AM, Robert Haas <robertmh...@gmail.com> wrote:
>> Based on KaiGai's analysis, it seems to me that there is no serious
>> problem here in terms of versioning, and as this patch represents a
>> small but useful step forward in our support for SELinux integration,
>> I'd like to go ahead and push it.
>>
>> Are there serious objections to that course of action?
>
> Sounds like not, but when I ran the sepgsql regression tests with this
> applied, they failed in the following way:
>
> *** /home/rhaas/pgsql/contrib/sepgsql/expected/label.out
> 2013-03-28 10:49:26.513998274 -0400
> --- /home/rhaas/pgsql/contrib/sepgsql/results/label.out 2013-03-28
> 10:50:50.818996744 -0400
> ***************
> *** 95,106 ****
>    column  | t3.tableoid | unconfined_u:object_r:user_sepgsql_table_t:s0
>    column  | t4.n        | unconfined_u:object_r:sepgsql_table_t:s0
>    column  | t4.m        | unconfined_u:object_r:sepgsql_table_t:s0
> !  column  | t4.ctid     | unconfined_u:object_r:sepgsql_sysobj_t:s0
> !  column  | t4.xmin     | unconfined_u:object_r:sepgsql_sysobj_t:s0
> !  column  | t4.cmin     | unconfined_u:object_r:sepgsql_sysobj_t:s0
> !  column  | t4.xmax     | unconfined_u:object_r:sepgsql_sysobj_t:s0
> !  column  | t4.cmax     | unconfined_u:object_r:sepgsql_sysobj_t:s0
> !  column  | t4.tableoid | unconfined_u:object_r:sepgsql_sysobj_t:s0
>   (16 rows)
>
>   --
> --- 95,106 ----
>    column  | t3.tableoid | unconfined_u:object_r:user_sepgsql_table_t:s0
>    column  | t4.n        | unconfined_u:object_r:sepgsql_table_t:s0
>    column  | t4.m        | unconfined_u:object_r:sepgsql_table_t:s0
> !  column  | t4.ctid     | unconfined_u:object_r:sepgsql_table_t:s0
> !  column  | t4.xmin     | unconfined_u:object_r:sepgsql_table_t:s0
> !  column  | t4.cmin     | unconfined_u:object_r:sepgsql_table_t:s0
> !  column  | t4.xmax     | unconfined_u:object_r:sepgsql_table_t:s0
> !  column  | t4.cmax     | unconfined_u:object_r:sepgsql_table_t:s0
> !  column  | t4.tableoid | unconfined_u:object_r:sepgsql_table_t:s0
>   (16 rows)
>
>   --
>
> Some trivial rebasing appears needed as well.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company



-- 
KaiGai Kohei <kai...@kaigai.gr.jp>


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to