| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> |
| 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 14:52:14 |
| Message-ID: | CA+TgmoYY1vq9u4wJ+JOd038pD=G2hOY-yeCFr_vWON9CtQ5X0g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2013-03-28 15:00:28 | Re: Catching resource leaks during WAL replay |
| Previous Message | Tom Lane | 2013-03-28 14:11:07 | Re: FDW for PostgreSQL |