Re: [sepgsql 1/3] add name qualified creation label - Mailing list pgsql-hackers

From Kohei KaiGai
Subject Re: [sepgsql 1/3] add name qualified creation label
Date
Msg-id CADyhKSUvyZRyxJS2L2En0CoKzVuHeeiWCCqKWayWvNh0Qn-wmA@mail.gmail.com
Whole thread Raw
In response to Re: [sepgsql 1/3] add name qualified creation label  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [sepgsql 1/3] add name qualified creation label
List pgsql-hackers
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-regtest1.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 <robertmhaas@gmail.com>:
> On Wed, Mar 27, 2013 at 8:41 AM, Robert Haas <robertmhaas@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 <kaigai@kaigai.gr.jp>



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: FDW for PostgreSQL
Next
From: Tom Lane
Date:
Subject: Extra security measures for next week's releases