[sepgsql 1/3] add name qualified creation label

This patch adds sepgsql the feature of name qualified creation label.

Background, on creation of a certain database object, sepgsql assigns
a default security label according to the security policy that has a set of
rules to determine a label of new object.
Usually, a new object inherits its parent (e.g table is a parent of column)
object's label, unless it has a particular type_transition rule in the policy.
Type_transition rule allows to describe a particular security label as
default label of new object towards a pair of client and parent object.
For example, the below rule says columns constructed under the table
labeled as "sepgsql_table_t" by client with "staff_t" will have
"staff_column_t", instead of table's label.
TYPE_TRANSITION staff_t sepgsql_table_t:db_column staff_column_t;

Recently, this rule was enhanced to take 5th argument for object name;
that enables to special case handling exceptionally.
It was originally designed to describe default security labels for files in
/etc directory, because many application put its own configuration files
here, thus, traditional type_transition rule was poor to describe all the
needed defaults.
On the other hand, we can port this concept of database system also.
One example is temporary objects being constructed under the pg_temp
schema. If we could assign a special default label on this, it allows
unprivileged users (who cannot create persistent tables) to create
temporary tables that has no risk of information leak to other users.
Otherwise, we may be able to assign a special security label on
system columns and so on.

From the perspective of implementation on sepgsql side, all we need
to do is replace old security_compute_create_raw() interface by new
security_compute_create_name_raw().
If here is no name qualified type_transition rules, it performs as if
existing API, so here is no backword compatible issue.

This patch can be applied on the latest master branch.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

On Tue, Jan 15, 2013 at 3:02 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> This patch adds sepgsql the feature of name qualified creation label.
>
> Background, on creation of a certain database object, sepgsql assigns
> a default security label according to the security policy that has a set of
> rules to determine a label of new object.
> Usually, a new object inherits its parent (e.g table is a parent of column)
> object's label, unless it has a particular type_transition rule in the policy.
> Type_transition rule allows to describe a particular security label as
> default label of new object towards a pair of client and parent object.
> For example, the below rule says columns constructed under the table
> labeled as "sepgsql_table_t" by client with "staff_t" will have
> "staff_column_t", instead of table's label.
> TYPE_TRANSITION staff_t sepgsql_table_t:db_column staff_column_t;
>
> Recently, this rule was enhanced to take 5th argument for object name;
> that enables to special case handling exceptionally.
> It was originally designed to describe default security labels for files in
> /etc directory, because many application put its own configuration files
> here, thus, traditional type_transition rule was poor to describe all the
> needed defaults.
> On the other hand, we can port this concept of database system also.
> One example is temporary objects being constructed under the pg_temp
> schema. If we could assign a special default label on this, it allows
> unprivileged users (who cannot create persistent tables) to create
> temporary tables that has no risk of information leak to other users.
> Otherwise, we may be able to assign a special security label on
> system columns and so on.
>
> From the perspective of implementation on sepgsql side, all we need
> to do is replace old security_compute_create_raw() interface by new
> security_compute_create_name_raw().
> If here is no name qualified type_transition rules, it performs as if
> existing API, so here is no backword compatible issue.
>
> This patch can be applied on the latest master branch.

This looks OK on a quick once-over, but should it update the
documentation somehow?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

2013/1/16 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Tue, Jan 15, 2013 at 3:02 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> This patch adds sepgsql the feature of name qualified creation label.
>>
>> Background, on creation of a certain database object, sepgsql assigns
>> a default security label according to the security policy that has a set of
>> rules to determine a label of new object.
>> Usually, a new object inherits its parent (e.g table is a parent of column)
>> object's label, unless it has a particular type_transition rule in the policy.
>> Type_transition rule allows to describe a particular security label as
>> default label of new object towards a pair of client and parent object.
>> For example, the below rule says columns constructed under the table
>> labeled as "sepgsql_table_t" by client with "staff_t" will have
>> "staff_column_t", instead of table's label.
>> TYPE_TRANSITION staff_t sepgsql_table_t:db_column staff_column_t;
>>
>> Recently, this rule was enhanced to take 5th argument for object name;
>> that enables to special case handling exceptionally.
>> It was originally designed to describe default security labels for files in
>> /etc directory, because many application put its own configuration files
>> here, thus, traditional type_transition rule was poor to describe all the
>> needed defaults.
>> On the other hand, we can port this concept of database system also.
>> One example is temporary objects being constructed under the pg_temp
>> schema. If we could assign a special default label on this, it allows
>> unprivileged users (who cannot create persistent tables) to create
>> temporary tables that has no risk of information leak to other users.
>> Otherwise, we may be able to assign a special security label on
>> system columns and so on.
>>
>> From the perspective of implementation on sepgsql side, all we need
>> to do is replace old security_compute_create_raw() interface by new
>> security_compute_create_name_raw().
>> If here is no name qualified type_transition rules, it performs as if
>> existing API, so here is no backword compatible issue.
>>
>> This patch can be applied on the latest master branch.
>
> This looks OK on a quick once-over, but should it update the
> documentation somehow?
>
Documentation does not take so much description for type_transition
rules, so I just modified relevant description a bit to mention about
type_transition rule may have argument of new object name optionally.
In addition, I forgot to update minimum required version for libselinux;
(it also takes change in configure script).
These two are the point to be updated in documentation.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

On 17.01.2013 23:20, Kohei KaiGai wrote:
> 2013/1/16 Robert Haas<robertmhaas(at)gmail(dot)com>:
>> This looks OK on a quick once-over, but should it update the
>> documentation somehow?
>>
> Documentation does not take so much description for type_transition
> rules, so I just modified relevant description a bit to mention about
> type_transition rule may have argument of new object name optionally.

The comments at least need updating, to mention the new arguments.

> In addition, I forgot to update minimum required version for libselinux;
> (it also takes change in configure script).

libselinux1 2.1.10 or newer is a pretty tall order. That's not in debian
testing yet, for example. I'm afraid if we bump the minimum requirement,
what might happen is that many distributions will stop building with
--with-selinux.

- Heikki

Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> On 17.01.2013 23:20, Kohei KaiGai wrote:
>> In addition, I forgot to update minimum required version for libselinux;
>> (it also takes change in configure script).

> libselinux1 2.1.10 or newer is a pretty tall order. That's not in debian
> testing yet, for example. I'm afraid if we bump the minimum requirement,
> what might happen is that many distributions will stop building with
> --with-selinux.

FWIW, in Fedora-land I see:

F16: 2.1.6 (F16 will go out of support next month)
F17: 2.1.10 (F17 has been stable for 6+ months)
F18: 2.1.12 (F18 just went stable)

While requiring 2.1.10 today might be thought a tad leading-edge,
will that still be true by the time we ship 9.3?

Or maybe we should just be punting this patch to 9.4, by which time the
version requirement should surely not be an issue within the community
that's likely to be using selinux at all. Unless I missed a previous
submission, this is a significant feature patch that did not show up in
time for CF3, which means that we should not be considering it at all
for 9.3 according to the rules that were agreed to in Ottawa last May.

regards, tom lane

On 1/23/2013 8:32 PM, Tom Lane wrote:
> FWIW, in Fedora-land I see:
>
> F16: 2.1.6 (F16 will go out of support next month)
> F17: 2.1.10 (F17 has been stable for 6+ months)
> F18: 2.1.12 (F18 just went stable)
>
> While requiring 2.1.10 today might be thought a tad leading-edge,
> will that still be true by the time we ship 9.3?

I'd be far more interested in what is in RHEL and CentOS. Fedora,
with its 6 month obsolescence cycle, is of zero interest to me for
deploying database servers.

EL6 has libselinux 2.0.94
EL5 has libselinux 1.33.4

John R Pierce <pierce(at)hogranch(dot)com> writes:
> On 1/23/2013 8:32 PM, Tom Lane wrote:
>> FWIW, in Fedora-land I see: ...

> I'd be far more interested in what is in RHEL and CentOS. Fedora,
> with its 6 month obsolescence cycle, is of zero interest to me for
> deploying database servers.

But of course Fedora is also the upstream that will become RHEL7
and beyond.

> EL6 has libselinux 2.0.94
> EL5 has libselinux 1.33.4

sepgsql already requires libselinux 2.0.99, so it doesn't appear to me
that moving that goalpost is going to change things one way or the other
for the existing RHEL branches. I couldn't ship contrib/sepgsql today
in those branches.

It might be that the update timing makes a bigger difference in some
other distros, though. To return to Heikki's original point about
Debian, what are they shipping today?

regards, tom lane

2013/1/24 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> John R Pierce <pierce(at)hogranch(dot)com> writes:
>> On 1/23/2013 8:32 PM, Tom Lane wrote:
>>> FWIW, in Fedora-land I see: ...
>
>> I'd be far more interested in what is in RHEL and CentOS. Fedora,
>> with its 6 month obsolescence cycle, is of zero interest to me for
>> deploying database servers.
>
> But of course Fedora is also the upstream that will become RHEL7
> and beyond.
>
>> EL6 has libselinux 2.0.94
>> EL5 has libselinux 1.33.4
>
> sepgsql already requires libselinux 2.0.99, so it doesn't appear to me
> that moving that goalpost is going to change things one way or the other
> for the existing RHEL branches. I couldn't ship contrib/sepgsql today
> in those branches.
>
> It might be that the update timing makes a bigger difference in some
> other distros, though. To return to Heikki's original point about
> Debian, what are they shipping today?
>
Even though I'm not good at release cycle of Debian, I tried to check
the shipped version of postgresql and libselinux for stable, testing,
unstable and experimental release.
I'm not certain why they don't push postgresql-9.2 into experimental
release yet. However, it seems to me optimistic libselinux-2.1.10 being
bundled on the timeline of postgresql-9.3.

If someone familiar with Debian's release cycle, I'd like to see the suggestion.

* Debian (stable) ... postgresql-8.4 + libselinux-2.0.96
http://packages.debian.org/en/squeeze/postgresql
http://packages.debian.org/en/source/squeeze/libselinux

* Debian (testing) ... postgresql-9.1 + libselinux-2.1.9
http://packages.debian.org/en/wheezy/postgresql
http://packages.debian.org/en/source/wheezy/libselinux

* Debian (unstable) ... postgresql-9.1 + libselinux-2.1.9
http://packages.debian.org/en/sid/postgresql
http://packages.debian.org/en/source/sid/libselinux

* Debian (experimental) ... postgresql-9.1 + libselinux-2.1.12
http://packages.debian.org/en/experimental/postgresql
http://packages.debian.org/en/source/experimental/libselinux

Also, Ubuntu almost reflects Debian's release.

* Ubuntu 11.10 ... postgresql-9.1 + libselinux-2.0.98
https://launchpad.net/ubuntu/oneiric/+package/postgresql
https://launchpad.net/ubuntu/oneiric/+source/libselinux

* Ubuntu 12.04 ... postgresql-9.1 + libselinux-2.1.0
https://launchpad.net/ubuntu/precise/+package/postgresql
https://launchpad.net/ubuntu/precise/+source/libselinux

* Ubuntu 12.10 ... postgresql-9.1 + libselinux-2.1.9
https://launchpad.net/ubuntu/quantal/+package/postgresql
https://launchpad.net/ubuntu/quantal/+source/libselinux

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

On Thu, Jan 24, 2013 at 10:11 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> 2013/1/24 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> John R Pierce <pierce(at)hogranch(dot)com> writes:
>>> On 1/23/2013 8:32 PM, Tom Lane wrote:
>>>> FWIW, in Fedora-land I see: ...
>>
>>> I'd be far more interested in what is in RHEL and CentOS. Fedora,
>>> with its 6 month obsolescence cycle, is of zero interest to me for
>>> deploying database servers.
>>
>> But of course Fedora is also the upstream that will become RHEL7
>> and beyond.

Do we know which version of Fedora will become RHEL7, and thus, which
version of libselinux will go in RHEL7? (And do we know which version
of postgres will go in RHEL7, assuming release schedules hold)

>> It might be that the update timing makes a bigger difference in some
>> other distros, though. To return to Heikki's original point about
>> Debian, what are they shipping today?
>>
> Even though I'm not good at release cycle of Debian, I tried to check
> the shipped version of postgresql and libselinux for stable, testing,
> unstable and experimental release.
> I'm not certain why they don't push postgresql-9.2 into experimental
> release yet. However, it seems to me optimistic libselinux-2.1.10 being
> bundled on the timeline of postgresql-9.3.
>
> If someone familiar with Debian's release cycle, I'd like to see the suggestion.
>
> * Debian (stable) ... postgresql-8.4 + libselinux-2.0.96
> http://packages.debian.org/en/squeeze/postgresql
> http://packages.debian.org/en/source/squeeze/libselinux
>
> * Debian (testing) ... postgresql-9.1 + libselinux-2.1.9
> http://packages.debian.org/en/wheezy/postgresql
> http://packages.debian.org/en/source/wheezy/libselinux

Just as a note, wheezy is the version that will be the next debian
stable, and it's in freeze since quite a while back. So we can safely
expect it will be 2.1.9 that's included in the next debian stable.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

2013/1/24 Magnus Hagander <magnus(at)hagander(dot)net>:
> On Thu, Jan 24, 2013 at 10:11 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> 2013/1/24 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>> John R Pierce <pierce(at)hogranch(dot)com> writes:
>>>> On 1/23/2013 8:32 PM, Tom Lane wrote:
>>>>> FWIW, in Fedora-land I see: ...
>>>
>>>> I'd be far more interested in what is in RHEL and CentOS. Fedora,
>>>> with its 6 month obsolescence cycle, is of zero interest to me for
>>>> deploying database servers.
>>>
>>> But of course Fedora is also the upstream that will become RHEL7
>>> and beyond.
>
> Do we know which version of Fedora will become RHEL7, and thus, which
> version of libselinux will go in RHEL7? (And do we know which version
> of postgres will go in RHEL7, assuming release schedules hold)
>
I'm not certain...

>>> It might be that the update timing makes a bigger difference in some
>>> other distros, though. To return to Heikki's original point about
>>> Debian, what are they shipping today?
>>>
>> Even though I'm not good at release cycle of Debian, I tried to check
>> the shipped version of postgresql and libselinux for stable, testing,
>> unstable and experimental release.
>> I'm not certain why they don't push postgresql-9.2 into experimental
>> release yet. However, it seems to me optimistic libselinux-2.1.10 being
>> bundled on the timeline of postgresql-9.3.
>>
>> If someone familiar with Debian's release cycle, I'd like to see the suggestion.
>>
>> * Debian (stable) ... postgresql-8.4 + libselinux-2.0.96
>> http://packages.debian.org/en/squeeze/postgresql
>> http://packages.debian.org/en/source/squeeze/libselinux
>>
>> * Debian (testing) ... postgresql-9.1 + libselinux-2.1.9
>> http://packages.debian.org/en/wheezy/postgresql
>> http://packages.debian.org/en/source/wheezy/libselinux
>
> Just as a note, wheezy is the version that will be the next debian
> stable, and it's in freeze since quite a while back. So we can safely
> expect it will be 2.1.9 that's included in the next debian stable.
>
It seems to me this means pgsql-9.1 shall be bundled with
libselinux-2.1.9, but not pgsql-9.3, so here is no matter.

When pgsql-9.3 is released, Fedora 17 will exceed end-of-life.
Debian already releases libselinux-2.1.12 on experimental package
even though its pgsql is 9.1. Is it too optimistic estimation?

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

2013/1/25 Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>:
> 2013/1/24 Magnus Hagander <magnus(at)hagander(dot)net>:
>> On Thu, Jan 24, 2013 at 10:11 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>>> 2013/1/24 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>>>> John R Pierce <pierce(at)hogranch(dot)com> writes:
>>>>> On 1/23/2013 8:32 PM, Tom Lane wrote:
>>>>>> FWIW, in Fedora-land I see: ...
>>>>
>>>>> I'd be far more interested in what is in RHEL and CentOS. Fedora,
>>>>> with its 6 month obsolescence cycle, is of zero interest to me for
>>>>> deploying database servers.
>>>>
>>>> But of course Fedora is also the upstream that will become RHEL7
>>>> and beyond.
>>
>> Do we know which version of Fedora will become RHEL7, and thus, which
>> version of libselinux will go in RHEL7? (And do we know which version
>> of postgres will go in RHEL7, assuming release schedules hold)
>>
> I'm not certain...
>
>>>> It might be that the update timing makes a bigger difference in some
>>>> other distros, though. To return to Heikki's original point about
>>>> Debian, what are they shipping today?
>>>>
>>> Even though I'm not good at release cycle of Debian, I tried to check
>>> the shipped version of postgresql and libselinux for stable, testing,
>>> unstable and experimental release.
>>> I'm not certain why they don't push postgresql-9.2 into experimental
>>> release yet. However, it seems to me optimistic libselinux-2.1.10 being
>>> bundled on the timeline of postgresql-9.3.
>>>
>>> If someone familiar with Debian's release cycle, I'd like to see the suggestion.
>>>
>>> * Debian (stable) ... postgresql-8.4 + libselinux-2.0.96
>>> http://packages.debian.org/en/squeeze/postgresql
>>> http://packages.debian.org/en/source/squeeze/libselinux
>>>
>>> * Debian (testing) ... postgresql-9.1 + libselinux-2.1.9
>>> http://packages.debian.org/en/wheezy/postgresql
>>> http://packages.debian.org/en/source/wheezy/libselinux
>>
>> Just as a note, wheezy is the version that will be the next debian
>> stable, and it's in freeze since quite a while back. So we can safely
>> expect it will be 2.1.9 that's included in the next debian stable.
>>
> It seems to me this means pgsql-9.1 shall be bundled with
> libselinux-2.1.9, but not pgsql-9.3, so here is no matter.
>
> When pgsql-9.3 is released, Fedora 17 will exceed end-of-life.
> Debian already releases libselinux-2.1.12 on experimental package
> even though its pgsql is 9.1. Is it too optimistic estimation?
>
I asked folks of Debian-JP how and when does package maintainer
pushes new versions. Usually, new versions shall be pushed to
unstable branch, then testing and stable. But it is now feature freeze
period thus it is prohibited to push new features to unstable.
Thus, newer libselinux (2.1.12) is now in experimental branch, but not
in unstable branch.
He also said, the newer libselinux will likely moved to unstable when
feature freeze is unlocked soon. The pgsql-v9.3 shall be released
several months later, so it also shall be pushed to unstable branch
several months later at least. It does not make problems.

Due to same reason, RHEL7 does not make a problem even if it
ships with pgsql-9.3, because the latest libselinux already support
2.1.10 feature. Thus, required libselinux version should be sufficient
when pgsql-9.3 become available on Fedora.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

On Fri, Jan 25, 2013 at 10:29 AM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> I asked folks of Debian-JP how and when does package maintainer
> pushes new versions. Usually, new versions shall be pushed to
> unstable branch, then testing and stable. But it is now feature freeze
> period thus it is prohibited to push new features to unstable.
> Thus, newer libselinux (2.1.12) is now in experimental branch, but not
> in unstable branch.
> He also said, the newer libselinux will likely moved to unstable when
> feature freeze is unlocked soon. The pgsql-v9.3 shall be released
> several months later, so it also shall be pushed to unstable branch
> several months later at least. It does not make problems.
>
> Due to same reason, RHEL7 does not make a problem even if it
> ships with pgsql-9.3, because the latest libselinux already support
> 2.1.10 feature. Thus, required libselinux version should be sufficient
> when pgsql-9.3 become available on Fedora.

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?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

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>

On Thu, Mar 28, 2013 at 12:33 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
> Thanks for your checking.
>
> I doubt of whether security policy module for this regression test is not
> installed on your test environment.

Ah, you are right. Sorry for the noise.

Committed.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company