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: