Re: [sepgsql 1/3] add name qualified creation label

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, John R Pierce <pierce(at)hogranch(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [sepgsql 1/3] add name qualified creation label
Date: 2013-03-28 16:33:24
Message-ID: CADyhKSUvyZRyxJS2L2En0CoKzVuHeeiWCCqKWayWvNh0Qn-wmA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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-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 <robertmhaas(at)gmail(dot)com>:
> On Wed, Mar 27, 2013 at 8:41 AM, Robert Haas <robertmhaas(at)gmail(dot)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(at)kaigai(dot)gr(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-03-28 17:03:05 Extra security measures for next week's releases
Previous Message Stephen Frost 2013-03-28 16:20:44 Re: FDW for PostgreSQL