Thread: One question about security label command
Greetings,
I got a problem when i used the 'security label on role ...' command to make a label for a database role.
It show me an error like "ERROR: unsupported object type: 1260".So i read the document about 'security label' command ,it show me like this:
SECURITY LABEL [ FOR provider ] ON
{ TABLE object_name | COLUMN table_name.column_name | AGGREGATE aggregate_name ( aggregate_signature ) | DATABASE object_name | DOMAIN object_name | EVENT TRIGGER object_name | FOREIGN TABLE object_name FUNCTION function_name ( [ [ argmode ] [ argname ] argtype [, ...] ] ) | LARGE OBJECT large_object_oid | MATERIALIZED VIEW object_name | [ PROCEDURAL ] LANGUAGE object_name | ROLE object_name | SCHEMA object_name | SEQUENCE object_name | TABLESPACE object_name | TYPE object_name | VIEW object_name
} IS 'label'
where aggregate_signature is:
* |
[ argmode ] [ argname ] argtype [ , ... ] |
[ [ argmode ] [ argname ] argtype [ , ... ] ] ORDER BY [ argmode ] [ argname ] argtype [ , ... ]The document show that it can support the object_name named role,so i want to ask what lead to the problem.Thanks.
Are you trying with sepgsql.so module?
From standpoint of SQL syntax, yep, SECURITY LABEL command support
the object types below, however, it fully depends on security label
provider; sepgsql.so in this case.
At this moment, it supports database, schema, function, tables and
column are supported by sepgsql. So, it is expected behavior.
Thanks,
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei <kaigai@ak.jp.nec.com>
> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of ?元超
> Sent: Tuesday, March 03, 2015 6:33 PM
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] One question about security label command
>
> Greetings,
> I got a problem when i used the 'security label on role ...' command to make
> a label for a database role.
> It show me an error like "ERROR: unsupported object type: 1260".So i read the
> document about 'security label' command ,it show me like this:
>
> SECURITY LABEL [ FOR provider ] ON
> {
> TABLE object_name |
> COLUMN table_name.column_name |
> AGGREGATE aggregate_name ( aggregate_signature ) |
> DATABASE object_name |
> DOMAIN object_name |
> EVENT TRIGGER object_name |
> FOREIGN TABLE object_name
> FUNCTION function_name ( [ [ argmode ] [ argname ] argtype [, ...] ] ) |
> LARGE OBJECT large_object_oid |
> MATERIALIZED VIEW object_name |
> [ PROCEDURAL ] LANGUAGE object_name |
> ROLE object_name |
> SCHEMA object_name |
> SEQUENCE object_name |
> TABLESPACE object_name |
> TYPE object_name |
> VIEW object_name
> } IS 'label'
>
> where aggregate_signature is:
>
> * |
> [ argmode ] [ argname ] argtype [ , ... ] |
> [ [ argmode ] [ argname ] argtype [ , ... ] ] ORDER BY [ argmode ] [ argname ]
> argtype [ , ... ]
> The document show that it can support the object_name named role,so i want to
> ask what lead to the problem.Thanks.
>
>
>
>
>
On Tue, Mar 3, 2015 at 5:01 AM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote: > From standpoint of SQL syntax, yep, SECURITY LABEL command support > the object types below, however, it fully depends on security label > provider; sepgsql.so in this case. > At this moment, it supports database, schema, function, tables and > column are supported by sepgsql. So, it is expected behavior. If the core system supports labels on other object types and sepgsql does not, it should give a better error for those cases, like: ERROR: sepgsql provider does not support labels on roles Errors like "ERROR: unsupported object type: 1260" are a good way to report a failure that is never expected to happen, but they shouldn't be used as user-facing error messages. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
The attached patch revises error message when security label is specified on unsupported object. getObjectTypeDescription() may be better than oid of catalog. postgres=# SECURITY LABEL FOR selinux ON ROLE kaigai postgres-# IS 'system_u:object_r:unlabeled_t:s0'; ERROR: sepgsql provider does not support labels on role 2015-03-09 23:55 GMT+09:00 Robert Haas <robertmhaas@gmail.com>: > On Tue, Mar 3, 2015 at 5:01 AM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote: >> From standpoint of SQL syntax, yep, SECURITY LABEL command support >> the object types below, however, it fully depends on security label >> provider; sepgsql.so in this case. >> At this moment, it supports database, schema, function, tables and >> column are supported by sepgsql. So, it is expected behavior. > > If the core system supports labels on other object types and sepgsql > does not, it should give a better error for those cases, like: > > ERROR: sepgsql provider does not support labels on roles > > Errors like "ERROR: unsupported object type: 1260" are a good way to > report a failure that is never expected to happen, but they shouldn't > be used as user-facing error messages. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- KaiGai Kohei <kaigai@kaigai.gr.jp>
Attachment
Kohei KaiGai wrote: > The attached patch revises error message when security label > is specified on unsupported object. > getObjectTypeDescription() may be better than oid of catalog. Agreed. > postgres=# SECURITY LABEL FOR selinux ON ROLE kaigai > postgres-# IS 'system_u:object_r:unlabeled_t:s0'; > ERROR: sepgsql provider does not support labels on role I'd make itsepgsql provider does not support labels on objects of type "%s" And perhaps make it an ereport also, with errcode etc. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Mar 10, 2015 at 9:41 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > And perhaps make it an ereport also, with errcode etc. Yeah, definitely. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
ERRCODE_FEATURE_NOT_SUPPORTED is suitable error code here. Please see the attached one. Thanks, 2015-03-11 4:34 GMT+09:00 Robert Haas <robertmhaas@gmail.com>: > On Tue, Mar 10, 2015 at 9:41 AM, Alvaro Herrera > <alvherre@2ndquadrant.com> wrote: >> And perhaps make it an ereport also, with errcode etc. > > Yeah, definitely. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company -- KaiGai Kohei <kaigai@kaigai.gr.jp>
Attachment
On Tue, Mar 10, 2015 at 6:58 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: > ERRCODE_FEATURE_NOT_SUPPORTED is suitable error code here. > Please see the attached one. Committed. I did not bother back-patching this, but I can do that if people think it's important. The sepgsql regression tests don't seem to pass for me any more; I wonder if some expected-output changes are needed as a result of core changes. I'm guessing these tests are not running in an automated fashion anywhere? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Attachment
Robert Haas wrote: > On Tue, Mar 10, 2015 at 6:58 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: > > ERRCODE_FEATURE_NOT_SUPPORTED is suitable error code here. > > Please see the attached one. > > Committed. I did not bother back-patching this, but I can do that if > people think it's important. I don't really care myself. > The sepgsql regression tests don't seem > to pass for me any more; I wonder if some expected-output changes are > needed as a result of core changes. > I'm guessing these tests are not running in an automated fashion anywhere? Oops, that's bad. I vaguely recall asking someone for a buildfarm animal running these tests, but I guess that didn't happen. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
2015-03-12 1:27 GMT+09:00 Alvaro Herrera <alvherre@2ndquadrant.com>: > Robert Haas wrote: >> On Tue, Mar 10, 2015 at 6:58 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: >> > ERRCODE_FEATURE_NOT_SUPPORTED is suitable error code here. >> > Please see the attached one. >> >> Committed. I did not bother back-patching this, but I can do that if >> people think it's important. > > I don't really care myself. > >> The sepgsql regression tests don't seem >> to pass for me any more; I wonder if some expected-output changes are >> needed as a result of core changes. >> I'm guessing these tests are not running in an automated fashion anywhere? > > Oops, that's bad. I vaguely recall asking someone for a buildfarm > animal running these tests, but I guess that didn't happen. > This regression test fail come from the base security policy of selinux. In the recent selinux-policy package, "unconfined" domain was changed to have unrestricted permission as literal. So, this test case relies multi- category policy restricts unconfined domain, but its assumption is not correct now. The attached patch fixes the policy module of regression test. However, I also think we may stop to rely permission set of pre-defined selinux domains. Instead of pre-defined one, sepgsql-regtest.te may be ought to define own domain with appropriate permission set independent from the base selinux-policy version. Please give me time to investigate. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
Attachment
Kohei KaiGai wrote: > This regression test fail come from the base security policy of selinux. > In the recent selinux-policy package, "unconfined" domain was changed > to have unrestricted permission as literal. So, this test case relies multi- > category policy restricts unconfined domain, but its assumption is not > correct now. Makes sense. > The attached patch fixes the policy module of regression test. What branches need this patch? Do we need a modified patch for earlier branches? Could you provide a buildfarm animal that runs the sepgsql test in all branches on a regular basis? > However, I also think we may stop to rely permission set of pre-defined > selinux domains. Instead of pre-defined one, sepgsql-regtest.te may be > ought to define own domain with appropriate permission set independent > from the base selinux-policy version. Is this something we would backpatch? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro, KaiGai,
* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Kohei KaiGai wrote:
>
> > This regression test fail come from the base security policy of selinux.
> > In the recent selinux-policy package, "unconfined" domain was changed
> > to have unrestricted permission as literal. So, this test case relies multi-
> > category policy restricts unconfined domain, but its assumption is not
> > correct now.
>
> Makes sense.
>
> > The attached patch fixes the policy module of regression test.
>
> What branches need this patch? Do we need a modified patch for
> earlier branches?
>
> Could you provide a buildfarm animal that runs the sepgsql test in all
> branches on a regular basis?
Would be great if KaiGai can, of course, but I'm planning to stand one
up here soon in any case.
> > However, I also think we may stop to rely permission set of pre-defined
> > selinux domains. Instead of pre-defined one, sepgsql-regtest.te may be
> > ought to define own domain with appropriate permission set independent
> > from the base selinux-policy version.
>
> Is this something we would backpatch?
As it's just a change to the regression tests, it seems like it'd be a
good idea to backpatch it to me as there's very low risk of it breaking
anything and it'd actually fix the tests when they're run.
Thanks!
Stephen
Stephen Frost <sfrost@snowman.net> writes:
> * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
>> Kohei KaiGai wrote:
>>> The attached patch fixes the policy module of regression test.
>> Is this something we would backpatch?
> As it's just a change to the regression tests, it seems like it'd be a
> good idea to backpatch it to me as there's very low risk of it breaking
> anything and it'd actually fix the tests when they're run.
Do we need to worry about machines that are still running the older
selinux policy? I'm not sure it's a net win if we fix the regression
tests for latest-and-shiniest by breaking them elsewhere. Especially
not if we're going to back-patch into older branches, which are likely
to be getting run on older platforms.
The idea of making the regression test entirely independent of the
system's policy would presumably solve this problem, so I'd kind of
like to see progress on that front.
regards, tom lane
Tom,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> The idea of making the regression test entirely independent of the
> system's policy would presumably solve this problem, so I'd kind of
> like to see progress on that front.
Apologies, I guess it wasn't clear, but that's what I was intending to
advocate.
Thanks,
Stephen
> * Tom Lane (tgl@sss.pgh.pa.us) wrote: > > The idea of making the regression test entirely independent of the > > system's policy would presumably solve this problem, so I'd kind of > > like to see progress on that front. > > Apologies, I guess it wasn't clear, but that's what I was intending to > advocate. > OK, I'll try to design a new regression test policy that is independent from the system's policy assumption, like unconfined domain. Please give me time for this work. Thanks, -- NEC OSS Promotion Center / PG-Strom Project KaiGai Kohei <kaigai@ak.jp.nec.com> > -----Original Message----- > From: Stephen Frost [mailto:sfrost@snowman.net] > Sent: Monday, March 16, 2015 7:16 AM > To: Tom Lane > Cc: Alvaro Herrera; Kohei KaiGai; Robert Haas; Kaigai Kouhei(海外 浩平); 张元 > 超; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] One question about security label command > > Tom, > > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > > The idea of making the regression test entirely independent of the > > system's policy would presumably solve this problem, so I'd kind of > > like to see progress on that front. > > Apologies, I guess it wasn't clear, but that's what I was intending to > advocate. > > Thanks, > > Stephen
The attached patch fixes the policy module of regression test.
However, I also think we may stop to rely permission set of pre-defined
selinux domains. Instead of pre-defined one, sepgsql-regtest.te may be
ought to define own domain with appropriate permission set independent
from the base selinux-policy version.
I have applied this patch and ran the tests. All seems to work except that I have a minor error in the 'label' regression tests. It is simply a result order issue, modifying the expected order in my environment resolves the issue. I have attached the 'regression.diffs' for reference as well, FWIW, I have also attached a patch that corrects this issue for me, hopefully it is useful.
-Adam
Adam Brightwell - adam.brightwell@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
Attachment
Kouhei Kaigai wrote: > > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > > > The idea of making the regression test entirely independent of the > > > system's policy would presumably solve this problem, so I'd kind of > > > like to see progress on that front. > > > > Apologies, I guess it wasn't clear, but that's what I was intending to > > advocate. > > > OK, I'll try to design a new regression test policy that is independent > from the system's policy assumption, like unconfined domain. > > Please give me time for this work. Any progress here? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Stephen Frost wrote: Hi, > * Alvaro Herrera (alvherre@2ndquadrant.com) wrote: > > Could you provide a buildfarm animal that runs the sepgsql test in all > > branches on a regular basis? > > Would be great if KaiGai can, of course, but I'm planning to stand one > up here soon in any case. I don't think this is done, is it? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
2015-05-01 7:40 GMT+09:00 Alvaro Herrera <alvherre@2ndquadrant.com>: > Kouhei Kaigai wrote: >> > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> > > The idea of making the regression test entirely independent of the >> > > system's policy would presumably solve this problem, so I'd kind of >> > > like to see progress on that front. >> > >> > Apologies, I guess it wasn't clear, but that's what I was intending to >> > advocate. >> > >> OK, I'll try to design a new regression test policy that is independent >> from the system's policy assumption, like unconfined domain. >> >> Please give me time for this work. > > Any progress here? > Not done. The last version I rebuild had a trouble on user/role transition from unconfined_u/unconfined_r to the self defined user/role... So, I'm trying to keep the user/role field (that is not redefined for several years) but to define self domain/types (that have been redefined multiple times) for the regression test at this moment. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
Alvaro, * Alvaro Herrera (alvherre@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Alvaro Herrera (alvherre@2ndquadrant.com) wrote: > > > > Could you provide a buildfarm animal that runs the sepgsql test in all > > > branches on a regular basis? > > > > Would be great if KaiGai can, of course, but I'm planning to stand one > > up here soon in any case. > > I don't think this is done, is it? No. We've been testing and working with sepgsql internally but haven't set up a buildfarm member yet. It's still on my todo list though. Thanks! Stephen
2015-05-01 9:52 GMT+09:00 Kohei KaiGai <kaigai@kaigai.gr.jp>: > 2015-05-01 7:40 GMT+09:00 Alvaro Herrera <alvherre@2ndquadrant.com>: >> Kouhei Kaigai wrote: >>> > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >>> > > The idea of making the regression test entirely independent of the >>> > > system's policy would presumably solve this problem, so I'd kind of >>> > > like to see progress on that front. >>> > >>> > Apologies, I guess it wasn't clear, but that's what I was intending to >>> > advocate. >>> > >>> OK, I'll try to design a new regression test policy that is independent >>> from the system's policy assumption, like unconfined domain. >>> >>> Please give me time for this work. >> >> Any progress here? >> > Not done. > The last version I rebuild had a trouble on user/role transition from > unconfined_u/unconfined_r to the self defined user/role... > So, I'm trying to keep the user/role field (that is not redefined for > several years) but to define self domain/types (that have been > redefined multiple times) for the regression test at this moment. > The second approach above works. I defined a own privileged domain (sepgsql_regtest_superuser_t) instead of system's unconfined_t domain. The reason why regression test gets failed was, definition of unconfined_t in the system default policy was changed to bypass multi-category rules; which our regression test depends on. So, the new sepgsql_regtest_superuser_t domain performs almost like as unconfined_t, but restricted by multi-category policy as traditional unconfined_t did. It is self defined domain, so will not affected by system policy change. Even though the sepgsql-regtest.te still uses unconfined_u and unconfined_r pair for selinux-user and role, it requires users to define additional selinux-user by hand if we try to define own one. In addition, its definition has not been changed for several years. So, I thought it has less risk to rely on unconfined_u/unconfined_r field unlike unconfined_t domain. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
Attachment
On Sun, May 10, 2015 at 3:15 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: > 2015-05-01 9:52 GMT+09:00 Kohei KaiGai <kaigai@kaigai.gr.jp>: >> 2015-05-01 7:40 GMT+09:00 Alvaro Herrera <alvherre@2ndquadrant.com>: >>> Kouhei Kaigai wrote: >>>> > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >>>> > > The idea of making the regression test entirely independent of the >>>> > > system's policy would presumably solve this problem, so I'd kind of >>>> > > like to see progress on that front. >>>> > >>>> > Apologies, I guess it wasn't clear, but that's what I was intending to >>>> > advocate. >>>> > >>>> OK, I'll try to design a new regression test policy that is independent >>>> from the system's policy assumption, like unconfined domain. >>>> >>>> Please give me time for this work. >>> >>> Any progress here? >>> >> Not done. >> The last version I rebuild had a trouble on user/role transition from >> unconfined_u/unconfined_r to the self defined user/role... >> So, I'm trying to keep the user/role field (that is not redefined for >> several years) but to define self domain/types (that have been >> redefined multiple times) for the regression test at this moment. >> > The second approach above works. > I defined a own privileged domain (sepgsql_regtest_superuser_t) > instead of system's unconfined_t domain. > The reason why regression test gets failed was, definition of > unconfined_t in the system default policy was changed to bypass > multi-category rules; which our regression test depends on. > So, the new sepgsql_regtest_superuser_t domain performs almost > like as unconfined_t, but restricted by multi-category policy as > traditional unconfined_t did. > It is self defined domain, so will not affected by system policy > change. > Even though the sepgsql-regtest.te still uses unconfined_u and > unconfined_r pair for selinux-user and role, it requires users to > define additional selinux-user by hand if we try to define own one. > In addition, its definition has not been changed for several years. > So, I thought it has less risk to rely on unconfined_u/unconfined_r > field unlike unconfined_t domain. Can you add this to the next CommitFest? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
2015-05-13 21:45 GMT+09:00 Robert Haas <robertmhaas@gmail.com>: > On Sun, May 10, 2015 at 3:15 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: >> 2015-05-01 9:52 GMT+09:00 Kohei KaiGai <kaigai@kaigai.gr.jp>: >>> 2015-05-01 7:40 GMT+09:00 Alvaro Herrera <alvherre@2ndquadrant.com>: >>>> Kouhei Kaigai wrote: >>>>> > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >>>>> > > The idea of making the regression test entirely independent of the >>>>> > > system's policy would presumably solve this problem, so I'd kind of >>>>> > > like to see progress on that front. >>>>> > >>>>> > Apologies, I guess it wasn't clear, but that's what I was intending to >>>>> > advocate. >>>>> > >>>>> OK, I'll try to design a new regression test policy that is independent >>>>> from the system's policy assumption, like unconfined domain. >>>>> >>>>> Please give me time for this work. >>>> >>>> Any progress here? >>>> >>> Not done. >>> The last version I rebuild had a trouble on user/role transition from >>> unconfined_u/unconfined_r to the self defined user/role... >>> So, I'm trying to keep the user/role field (that is not redefined for >>> several years) but to define self domain/types (that have been >>> redefined multiple times) for the regression test at this moment. >>> >> The second approach above works. >> I defined a own privileged domain (sepgsql_regtest_superuser_t) >> instead of system's unconfined_t domain. >> The reason why regression test gets failed was, definition of >> unconfined_t in the system default policy was changed to bypass >> multi-category rules; which our regression test depends on. >> So, the new sepgsql_regtest_superuser_t domain performs almost >> like as unconfined_t, but restricted by multi-category policy as >> traditional unconfined_t did. >> It is self defined domain, so will not affected by system policy >> change. >> Even though the sepgsql-regtest.te still uses unconfined_u and >> unconfined_r pair for selinux-user and role, it requires users to >> define additional selinux-user by hand if we try to define own one. >> In addition, its definition has not been changed for several years. >> So, I thought it has less risk to rely on unconfined_u/unconfined_r >> field unlike unconfined_t domain. > > Can you add this to the next CommitFest? > OK, done https://commitfest.postgresql.org/5/249/ -- KaiGai Kohei <kaigai@kaigai.gr.jp>
On 05/13/2015 03:49 PM, Kohei KaiGai wrote: > 2015-05-13 21:45 GMT+09:00 Robert Haas <robertmhaas@gmail.com>: >> Can you add this to the next CommitFest? >> > OK, done > > https://commitfest.postgresql.org/5/249/ Aaand the commitfest has began.. Stephen, would you have the time to review this patch, and commit if appropriate, please? And if you could set up the buildfarm animal to run this, even better. - Heikki
Stephen, > Stephen, would you have the time to review this patch, and commit if > appropriate, please? And if you could set up the buildfarm animal to run > this, even better. I gave this a quick review/test against master (0a0fe2f). Everything builds and installs as would be expected. All of the context changes make sense to me. However, I am still seeing some errors in the regression tests. The errors look like they are solely based around log messages and not 'functionality'. I have attached the 'regression.diffs' for reference. -Adam -- Adam Brightwell - adam.brightwell@crunchydatasolutions.com Database Engineer - www.crunchydatasolutions.com
Attachment
All, > The second approach above works. > I defined a own privileged domain (sepgsql_regtest_superuser_t) > instead of system's unconfined_t domain. > The reason why regression test gets failed was, definition of > unconfined_t in the system default policy was changed to bypass > multi-category rules; which our regression test depends on. > So, the new sepgsql_regtest_superuser_t domain performs almost > like as unconfined_t, but restricted by multi-category policy as > traditional unconfined_t did. > It is self defined domain, so will not affected by system policy > change. > Even though the sepgsql-regtest.te still uses unconfined_u and > unconfined_r pair for selinux-user and role, it requires users to > define additional selinux-user by hand if we try to define own one. > In addition, its definition has not been changed for several years. > So, I thought it has less risk to rely on unconfined_u/unconfined_r > field unlike unconfined_t domain. I have reviewed and tested this patch against 'master' at 781ed2b. The patch applies without issue and all tests pass on EL7. -Adam -- Adam Brightwell - adam.brightwell@crunchydatasolutions.com Database Engineer - www.crunchydatasolutions.com
So what about the buildfarm animal that was offered for this? We still have this module completely uncovered in the buildfarm ... -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> So what about the buildfarm animal that was offered for this? We still > have this module completely uncovered in the buildfarm ... I believe that is in the works and should be made available soon. -Adam -- Adam Brightwell - adam.brightwell@crunchydatasolutions.com Database Engineer - www.crunchydatasolutions.com
* Adam Brightwell (adam.brightwell@crunchydatasolutions.com) wrote:
> > So what about the buildfarm animal that was offered for this? We still
> > have this module completely uncovered in the buildfarm ...
>
> I believe that is in the works and should be made available soon.
Right, Joe commented on the 'open commitfest items' thread that he's
working on getting it set up (actually, more than one; aiui he's
building both a RHEL 6 one and a RHEL 7 one).
Thanks!
Stephen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/25/2015 01:02 PM, Stephen Frost wrote: > * Adam Brightwell (adam.brightwell@crunchydatasolutions.com) > wrote: >>> So what about the buildfarm animal that was offered for this? >>> We still have this module completely uncovered in the buildfarm >>> ... >> >> I believe that is in the works and should be made available >> soon. > > Right, Joe commented on the 'open commitfest items' thread that > he's working on getting it set up (actually, more than one; aiui > he's building both a RHEL 6 one and a RHEL 7 one). Yeah, I'm working on it. I also have reviewed and tested the patch on rhel7.1 and am working on rhel6.7. Joe - -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV3N3cAAoJEDfy90M199hl+8cP/iczkjAmz9J87/+wUfXDWj5C rRCa4K9gxngU96u7LZeiufaAIj5Y84jJZlV+L9mpt2eHmWyxAbIUBGEt7bk0aN3u tXsSBNXbtl3iTDK2QsZTBXiAUbXBKjSjpjyPRNggnpbPK8nEEgUTlV/WQmU5pgWc V1fODx89tDROM5hhGxy6l4Q6bFnJaLSoVnnUT/+yJiZIyeN0TfzL+ekRdoyyrQYL WR8bOPG2AVAHJH2saFDwJ8FbeohOgs87gW5U0eO40oGz21TJzsHMcdJRLYa8B650 6eJH1pV2YKhqSaeUjCqNOpie3EFBDlNmWmO92BhVC3oTDWxRLtObeoq9BB/B8tEz XCy+to/aLB/d+Bntmkg5SoV7ODHLQdH6qHaXcemallNCz4/uTP9Cm8oDPL6eu7bj AOeMx5cYDpvIKMjSRBsAEMxAfepc1VgAfxdthOBoYcswKXz1c3BIn3SjQnNQk78R vhg4walAKGXT+dOfROdOaUcNUODpf18M2CPTAYm8M+uC/vcb+7j8MlRc+0xIz/LA 0iNLQAjdWDsSwiRqrt+GfV4peoSqwJenyGRhdOeRES33U+pT6kWWxSYy43cgLlso GcT49DwSWDxwjU+9EtA2Rdxa/yBCAcrDQOwT2N/FQr2QQUB8WFfbAIq2G8fUl2q5 ZjAChs3KMSuWQJoVuwMN =RVIH -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/25/2015 02:27 PM, Joe Conway wrote: > On 08/25/2015 01:02 PM, Stephen Frost wrote: >> * Adam Brightwell (adam.brightwell@crunchydatasolutions.com) >> wrote: >>>> So what about the buildfarm animal that was offered for >>>> this? We still have this module completely uncovered in the >>>> buildfarm ... >>> >>> I believe that is in the works and should be made available >>> soon. > >> Right, Joe commented on the 'open commitfest items' thread that >> he's working on getting it set up (actually, more than one; aiui >> he's building both a RHEL 6 one and a RHEL 7 one). > > Yeah, I'm working on it. I also have reviewed and tested the patch > on rhel7.1 and am working on rhel6.7. I'm arriving late to this party, so maybe everyone else already knows this, but apparently sepgsql is not compatible with the version of selinux available on RHEL 6.x. So there doesn't seem to be much reason for a RHEL 6.x buildfarm animal just for sepgsql testing as it will always fail ;-) As I have never before set up a build farm animal, and since sepgsql cannot be run directly with `make installcheck`, nor can sepgsql be installed in the usual manner, this may not be a slam dunk... Joe - -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV3RB4AAoJEDfy90M199hlsg0P/2cPCkqbDpOzFLQzUi/MvgMs CORS98FiAy/PYYhFBs75XJo39uSOX7nzk9M/tAAfFgjvV1jl8QUW0kFvBKE3P8bI M93ZUT3tSG51cpfhj+Gaj6uvC3c7GVOj14vhvXOS+Mg8qaGfoa1kzJi4ku4Ajt/H UurJWq529sTTETgGdpaMJgW1bLfseRJFjTN60FZI3DSUQZgQ6WuqIJ6tk8XhS0Sk r6iTCeS3Z6QsiM3g20UIjLXfc+1Ju6AiZZbG4zeRkt6T5FlgofCS+3tDGF3Lnr0Q ZGG5J9F5cpX+xEX7gNmWaPFvnb+PyLiqPDGMLFEWqrs6ST/IKT6TI2z8C6+PKmBX t8wrDu3vZSGlWwosg3iN3UbzQcH2omuPbpZwiBf+fCMVpmp9IBr/itwL7rShI9Wp NHAoU3o3f+Skgt/D/QEgGhGcjb7toftKxJcrhtnoDrCSXMd2XH7YxMbRamSIcQNq Ih/lGfGNNdfJjcS3upnsgQuEnIHzqxIA2R8BprEz5E3LNTWQ74pe74UXOxvhLIfc H9bXHeRZebvukue0GOO9HbArrAFB6FxsHgYtipY1o5VAxBTuQIvWv+tDXZnrPjud Kce/eHEK6JLsIkuHmKYU4hsZPMIQYSBqv6z8aFHJa9bEaMrv6eQ4VvZ9DL+Xt7z5 9iRVlEUnOZ1FD7jebJTh =+kmo -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/25/2015 06:03 PM, Joe Conway wrote: > I'm arriving late to this party, so maybe everyone else already > knows this, but apparently sepgsql is not compatible with the > version of selinux available on RHEL 6.x. So there doesn't seem to > be much reason for a RHEL 6.x buildfarm animal just for sepgsql > testing as it will always fail ;-) Just to be clear, I have marked this on the commitfest app as ready for commit, and plan to commit it soon. Figuring out the buildfarm animal will be my next task after that. Joe - -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV3RxQAAoJEDfy90M199hlkHQP/AtzBbKFxCFuNBKr/nTpvSOx Sb2N0SdQINA/VbXYIS5yN4R4rUi33ZmCcDfQNs690X0feB2BF4cWpw2xHKyQSXZa B2oxScwtW+ReiADIILjrfv14tK4IAq6lWDVlLD7f+yAwvpjMNPb4S7+qcFoDnP2A weGlhpaQETpWqLMmM89QG3HN62hQeoSt1Zv9NiFDMyDso63jW/hgFELL8PFUeLtv 49tEI/ClaKLldLdu7uMJOouU9bsrxJzsnDRI4yf9tNotuzCjd9RW2P/CBVQMP1EV YWfhxY8hxonEg1NLFc4Wvj5xkQuRpTyMPQnZQoHfQaLPM7Qfvi1oqn4xRBKMpi5u gK/9B3w2oUO9CZAWM7HPnLgULZv+MXuUD3rYhVIlq4fPlgaD6lkHE1sbVC4W38jz L9gyDycOSkaMU+FDtRSrH0TwSoMgtybMDdTRTxddVxDFIeh8f15rJISpPq1xmsAZ pE71SVOf88Lo2TXliwh1sEeN7bZO/Hc/eUefKC4UVWgV/FbEnpQBT9U7qRuZBNIM +mr9FKtdX/Gp0NzWLQRozS+lQJhG0j6iM3DG6kTPlqh7sqfcxgqbwQpnjudIRILE 89FrkwXfEX0OziW8h54fdmYakTlQqH9sPt8XG9i1lOmHRNtnQCnTuit4sLr/rkko v9tq3xliqP3TtQXeRssY =MxPX -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/25/2015 06:54 PM, Joe Conway wrote:
> On 08/25/2015 06:03 PM, Joe Conway wrote:
>> I'm arriving late to this party, so maybe everyone else already
>> knows this, but apparently sepgsql is not compatible with the
>> version of selinux available on RHEL 6.x. So there doesn't seem
>> to be much reason for a RHEL 6.x buildfarm animal just for
>> sepgsql testing as it will always fail ;-)
>
> Just to be clear, I have marked this on the commitfest app as
> ready for commit, and plan to commit it soon. Figuring out the
> buildfarm animal will be my next task after that.
Here's a synopsis of the state of play with respect to sepgsql
regression tests:
Required
PG Ver RHEL Ver* test w/patch test w/o patch
- ------ --------- ------------ --------------
HEAD 7.x OK NOK
9.5 7.x OK NOK
9.4 7.x OK** NOK
9.3 7.x OK** NOK
9.2 7.x NOK NOK
9.1 6.x NOK OK
9.0*** N/A N/A N/A
- ------ --------- ------------ --------------
* It is really the version of libselinux.so that matters here. RHEL
7.x has libselinux 2.2.x whereas RHEL 6.x has 2.0.x. The latter lacks
functionality required by sepgsql starting with PG 9.2.
** As noted in an earlier message on this thread by Adam, with PG 9.4
(and 9.3) there is some addition noise coming from differences in
default verbosity or possibly error context hiding added after 9.4,
which causes the regression to fail with Kouhei's patch. Attached is a
slightly modified patch that works for 9.4 and 9.3.
*** sepgsql was introduced in PG 9.1
So given all that, here is what I propose we do:
1.) Commit Kouhei's patch against HEAD and 9.5 (Joe)
2.) Commit my modified patch against 9.4 and 9.3 (Joe)
3.) Rework patch for 9.2 (Kouhei)
4.) Finish standing up the RHEL/CentOS 7.x buildfarm member to
test sepgsql on 9.2 and up. The animal (rhinoceros) is running
already, but still needs some custom scripting. (Joe, Andrew)
5.) Additionally stand up a RHEL/CentOS 6.x buildfarm member to test
sepgsql on 9.1 (no changes) (Joe).
Sound like a plan?
Joe
- --
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJV4IA5AAoJEDfy90M199hlF6wP/1p0xpVORBY4DLjLaM8KzAWt
HxZjtK6vD8yQCG45L1crhYnB2FYIHZoG+71WwP7xSZ6YnOC+g5mFrjh6YdRMxwSe
OSnMIuy7QvVZrGfvSSIG6u4lBivi9jDC6mnFuU5YW9Q3mk6HBdJbErIuwP3z0Bxj
c9yuh6WqWRNghVwIyErkdbp7YqFDeoQZ8iSiKxDghMIQRzFgB4K1egEDM6TGAo/1
/1j0vSLmRoQPZvDnJaLCAsZzw7JozppwCXPwfpwd2Xj6N3h/v9aoflRKaKppvf16
vIqDcHkdbea3Bk/jGS3OBBMBXDsd5lrfjF5iaFVtiBu04VjUaJJ0mHOKNL+xf4Uk
E9C8bjxpR7MEeiR8tE8RTMWg710ITVix3P8I3y+LS0V8GhzaHw2AOKSlGVNlRf/Y
VfoFEcvqcqsnenA3gmUbljSeHI0G3G5w+nTwEvciug28PffnpNyamtjPOn4IEay4
12RrbD/v7IfsXxjnDqhQRLdy1t7tVDjNC6ddjSfT3G64v4pvBoSaT9NQXWJ9jw3A
aM345gguBRVGcKRD/UZfUZ4VBesj5T67g56HPmEqDC+7LlqVBSmKdEJ51RrfRsKF
fd8OZT43h9+XXD4yCuxt0bt38ybiRsOAdjT4eUrTj18GGx0q3P08NNnZI2V0fe4b
/8pM9IlcdxDYGS7e3oPv
=SbW3
-----END PGP SIGNATURE-----
Attachment
> * It is really the version of libselinux.so that matters here. RHEL > 7.x has libselinux 2.2.x whereas RHEL 6.x has 2.0.x. The latter lacks > functionality required by sepgsql starting with PG 9.2. Yes, that has been my observation as well. > So given all that, here is what I propose we do: > > 1.) Commit Kouhei's patch against HEAD and 9.5 (Joe) > 2.) Commit my modified patch against 9.4 and 9.3 (Joe) > 3.) Rework patch for 9.2 (Kouhei) > 4.) Finish standing up the RHEL/CentOS 7.x buildfarm member to > test sepgsql on 9.2 and up. The animal (rhinoceros) is running > already, but still needs some custom scripting. (Joe, Andrew) > 5.) Additionally stand up a RHEL/CentOS 6.x buildfarm member to test > sepgsql on 9.1 (no changes) (Joe). > > Sound like a plan? I think this makes sense. Getting buildfarm coverage on any level is better than nothing, IMHO. Kind of a bummer that 9.1 is the only version that will work as-is on EL6 but it is what it is for now, I suppose. -Adam -- Adam Brightwell - adam.brightwell@crunchydatasolutions.com Database Engineer - www.crunchydatasolutions.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/28/2015 07:21 PM, Adam Brightwell wrote: > On 08/28/2015 08:37 AM, Joe Conway wrote: >> So given all that, here is what I propose we do: >> >> 1.) Commit Kouhei's patch against HEAD and 9.5 (Joe) 2.) Commit >> my modified patch against 9.4 and 9.3 (Joe) 3.) Rework patch for >> 9.2 (Kouhei) 4.) Finish standing up the RHEL/CentOS 7.x buildfarm >> member to test sepgsql on 9.2 and up. The animal (rhinoceros) is >> running already, but still needs some custom scripting. (Joe, >> Andrew) 5.) Additionally stand up a RHEL/CentOS 6.x buildfarm >> member to test sepgsql on 9.1 (no changes) (Joe). >> >> Sound like a plan? > > I think this makes sense. Getting buildfarm coverage on any level > is better than nothing, IMHO. Kind of a bummer that 9.1 is the > only version that will work as-is on EL6 but it is what it is for > now, I suppose. #1 and 2 above are done -- committed and pushed to HEAD and 9.3-9.5. Additionally I have #5 (the 6.x buildfarm member) created/working and I sent in my registration form. It has not been accepted yet. Joe - -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV40i4AAoJEDfy90M199hlFK4P/iBkQk1oboo9OlnRgIT3w/be tCoL95E3ZH7SPEuxq0lbbCM6Hvz5lFWw0X9RQBJlUFBaIPjoilGrcf8r6COSfZZt XOTwmQJMDO7iCmBuc89ZrVH5Fz3rc19eA6p7bNplwesWOtXP/RwRObjtffi2XHOz pOuUqHpw9GBK4uVEf7v9Fdqz48OUYGa/MAMlw3XlBzgBKdx8l+bjBh/5YQFvRwBr ujNb9c/1DfEvtr/oaa7rmkKNUVmL53bEZbL6m81+taCKbvt7yD5GAN5Sdqw27iiy HILGwmdzlVzd+VMIJ7+53w2HpimIEVXCnn2yrM1rWL12b9oFmz/rCA1qfuyrGIN9 9ZFb+q3myCq/ofzXoznsBUIYxQhAfuLyRDrAUPEi8h4wWDc3JPJJkKmu/6ZuBGv7 m2g3mUx9sr7BoJKVZ4Vkqc4mgorwDkwzfJpiH0hKBewtO3WkN8LHk/jGTZaPgMwl 4OjJQvmCBk/5vdsfOQ/qZHqw6WM75gnxKGvHo/nFPuztzawXVx4sVWm2e4HxZlAP tfrTZtAYTE1K5y6Kn6yIeQgW4ZTwztIsjuG0XebTAymnHIjqkkj5RHpn93PADbrh wHvs6+nQAePdWoQ2LPwlWNELUxRz107BMnWBCHYk+cqoim48GE0UIHTLZQtR7C5D wIo5lU81nUqPI147940K =AB+P -----END PGP SIGNATURE-----
On 08/30/2015 11:17 AM, Joe Conway wrote: >>> 3.) Rework patch for 9.2 (Kohei) >>> 4.) Finish standing up the RHEL/CentOS 7.x buildfarm member to >>> test sepgsql on 9.2 and up. The animal (rhinoceros) is running >>> already, but still needs some custom scripting. (Joe, Andrew) >>> 5.) Additionally stand up a RHEL/CentOS 6.x buildfarm member to >>> test sepgsql on 9.1 (no changes) (Joe). > Additionally I have #5 (the 6.x buildfarm member) created/working and > I sent in my registration form. It has not been accepted yet. Many thanks to Andrew -- #4 and 5 now complete. Rhinoceros is now successfully testing sepgsql for 9.2 -> HEAD on CentOS 7.1, and a new animal, agama, is testing 9.1 on CentOS 6.7. Remember, expect 9.2 to fail until/unless we get a reworked patch for it. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Hi Joe, > >>> 3.) Rework patch for 9.2 (Kohei) > Could you wait for the next Monday? I'll try to work this in the next weekend. -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kaigai@ak.jp.nec.com> > -----Original Message----- > From: Joe Conway [mailto:mail@joeconway.com] > Sent: Tuesday, September 08, 2015 6:54 AM > To: Adam Brightwell > Cc: Stephen Frost; Alvaro Herrera; Kohei KaiGai; Kaigai Kouhei(海外 浩平); Tom > Lane; Robert Haas; 张元超; pgsql-hackers@postgresql.org; > adam.brightwell@crunchydata.com > Subject: Re: [HACKERS] One question about security label command > > On 08/30/2015 11:17 AM, Joe Conway wrote: > >>> 3.) Rework patch for 9.2 (Kohei) > > >>> 4.) Finish standing up the RHEL/CentOS 7.x buildfarm member to > >>> test sepgsql on 9.2 and up. The animal (rhinoceros) is running > >>> already, but still needs some custom scripting. (Joe, Andrew) > > >>> 5.) Additionally stand up a RHEL/CentOS 6.x buildfarm member to > >>> test sepgsql on 9.1 (no changes) (Joe). > > > Additionally I have #5 (the 6.x buildfarm member) created/working and > > I sent in my registration form. It has not been accepted yet. > > Many thanks to Andrew -- #4 and 5 now complete. Rhinoceros is now > successfully testing sepgsql for 9.2 -> HEAD on CentOS 7.1, and a new > animal, agama, is testing 9.1 on CentOS 6.7. > > Remember, expect 9.2 to fail until/unless we get a reworked patch for it. > > Joe > > -- > Crunchy Data - http://crunchydata.com > PostgreSQL Support for Secure Enterprises > Consulting, Training, & Open Source Development
On 09/07/2015 04:46 PM, Kouhei Kaigai wrote: >>>>> 3.) Rework patch for 9.2 (Kohei) >> > Could you wait for the next Monday? > I'll try to work this in the next weekend. Sure, that would be great. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Hi Joe, The attached one is the regression test fixup in v9.2. As we applied to the v9.3 or later, it replaces unconfined_t domain by the self defined sepgsql_regtest_superuser_t. Unfortunately, I found a bug to process SELECT INTO statement. Because v9.2 didn't have ObjectAccessPostCreate to inform the context when a relation is newly created, thus, sepgsql had an ugly alternative at sepgsql_executor_start(). It saves kind of statement prior to executor start, then it is referenced when sepgsql_relation_post_create() is called. However, T_CreateTableAsStmt was oversight, thus it is considered as a harmless internal operation, and no label was assigned on the new relation. I'm not certain why we oversight at that time, however, this logic is removed and replaced in v9.3. Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kaigai@ak.jp.nec.com> > -----Original Message----- > From: Joe Conway [mailto:mail@joeconway.com] > Sent: Tuesday, September 08, 2015 10:15 AM > To: Kaigai Kouhei(海外 浩平); Adam Brightwell > Cc: Stephen Frost; Alvaro Herrera; Kohei KaiGai; Tom Lane; Robert Haas; 张元 > 超; pgsql-hackers@postgresql.org; adam.brightwell@crunchydata.com > Subject: Re: [HACKERS] One question about security label command > > On 09/07/2015 04:46 PM, Kouhei Kaigai wrote: > >>>>> 3.) Rework patch for 9.2 (Kohei) > >> > > Could you wait for the next Monday? > > I'll try to work this in the next weekend. > > Sure, that would be great. > > Joe > > -- > Crunchy Data - http://crunchydata.com > PostgreSQL Support for Secure Enterprises > Consulting, Training, & Open Source Development
Attachment
On 09/13/2015 10:29 AM, Kouhei Kaigai wrote: > The attached one is the regression test fixup in v9.2. > As we applied to the v9.3 or later, it replaces unconfined_t domain > by the self defined sepgsql_regtest_superuser_t. > > Unfortunately, I found a bug to process SELECT INTO statement. > Because v9.2 didn't have ObjectAccessPostCreate to inform the > context when a relation is newly created, thus, sepgsql had > an ugly alternative at sepgsql_executor_start(). > It saves kind of statement prior to executor start, then it is > referenced when sepgsql_relation_post_create() is called. > However, T_CreateTableAsStmt was oversight, thus it is considered > as a harmless internal operation, and no label was assigned on > the new relation. > I'm not certain why we oversight at that time, however, this logic > is removed and replaced in v9.3. Thanks -- I'll look through this over the next day or two. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
On 09/15/2015 11:36 AM, Joe Conway wrote: > On 09/13/2015 10:29 AM, Kouhei Kaigai wrote: >> The attached one is the regression test fixup in v9.2. >> As we applied to the v9.3 or later, it replaces unconfined_t domain >> by the self defined sepgsql_regtest_superuser_t. > Thanks -- I'll look through this over the next day or two. Took a bit longer than I thought but now pushed :-) At this point all current branches should be passing the sepgsql regression test. As a reminder, that would be: rhino: 9.2 through master agama: 9.1 Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development