One question about security label command

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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

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>

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 it
sepgsql 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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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>

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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>

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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>

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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