Re: [HACKERS] One question about security label command
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 signature.asc Description: OpenPGP digital signature
Re: [HACKERS] One question about security label command
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 signature.asc Description: OpenPGP digital signature
Re: [HACKERS] One question about security label command
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 <kai...@ak.jp.nec.com> > -Original Message- > From: Joe Conway [mailto:m...@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.brightw...@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 sepgsql-fixup-regtest-policy.v9.2.patch Description: sepgsql-fixup-regtest-policy.v9.2.patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
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 signature.asc Description: OpenPGP digital signature
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 signature.asc Description: OpenPGP digital signature
Re: [HACKERS] One question about security label command
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 <kai...@ak.jp.nec.com> > -Original Message- > From: Joe Conway [mailto:m...@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.brightw...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] One question about security label command
-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- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] One question about security label command
-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/patchtest w/o patch
- --- --
HEAD 7.x OK NOK
9.57.x OK NOK
9.47.x OK** NOK
9.37.x OK** NOK
9.27.x NOK NOK
9.16.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-
diff --git a/contrib/sepgsql/expected/alter.out b/contrib/sepgsql/expected/alter.out
index 124f862..e67cc2d 100644
--- a/contrib/sepgsql/expected/alter.out
+++ b/contrib/sepgsql/expected/alter.out
@@ -8,9 +8,9 @@ DROP DATABASE IF EXISTS regtest_sepgsql_test_database;
DROP USER IF EXISTS regtest_sepgsql_test_user;
RESET client_min_messages;
SELECT sepgsql_getcon(); -- confirm client privilege
- sepgsql_getcon
- unconfined_u:unconfined_r:unconfined_t:s0
+ sepgsql_getcon
+--
+ unconfined_u:unconfined_r:sepgsql_regtest_superuser_t:s0
(1 row)
--
@@ -40,140 +40,136 @@ SET client_min_messages = LOG;
-- owner is not actually changed.
--
ALTER DATABASE regtest_sepgsql_test_database_1 OWNER TO regtest_sepgsql_test_user;
-LOG: SELinux: allowed { setattr } scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=unconfined_u:object_r:sepgsql_db_t:s0 tclass=db_database name=regtest_sepgsql_test_database_1
+LOG: SELinux: allowed { setattr } scontext=unconfined_u:unconfined_r:sepgsql_regtest_superuser_t:s0 tcontext=unconfined_u:object_r:sepgsql_db_t:s0 tclass=db_database name=regtest_sepgsql_test_database_1
ALTER DATABASE regtest_sepgsql_test_database_1 OWNER TO regtest_sepgsql_test_user;
-LOG: SELinux: allowed { setattr } scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=unconfined_u:object_r:sepgsql_db_t:s0 tclass=db_database name=regtest_sepgsql_test_database_1
+LOG: SELinux: allowed { setattr } scontext=unconfined_u:unconfined_r:sepgsql_regtest_superuser_t:s0
Re: [HACKERS] One question about security label command
* 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.brightw...@crunchydatasolutions.com Database Engineer - www.crunchydatasolutions.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] One question about security label command
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.brightw...@crunchydatasolutions.com Database Engineer - www.crunchydatasolutions.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] One question about security label command
So what about the buildfarm animal that was offered for this? We still have this module completely uncovered in the buildfarm ... -- Álvaro Herrerahttp://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
Re: [HACKERS] One question about security label command
* Adam Brightwell (adam.brightw...@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 signature.asc Description: Digital signature
Re: [HACKERS] One question about security label command
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.brightw...@crunchydatasolutions.com Database Engineer - www.crunchydatasolutions.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] One question about security label command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/25/2015 01:02 PM, Stephen Frost wrote: * Adam Brightwell (adam.brightw...@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- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] One question about security label command
-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.brightw...@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- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] One question about security label command
-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- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] One question about security label command
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.brightw...@crunchydatasolutions.com Database Engineer - www.crunchydatasolutions.com regression.diffs Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] One question about security label command
2015-05-13 21:45 GMT+09:00 Robert Haas robertmh...@gmail.com: On Sun, May 10, 2015 at 3:15 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote: 2015-05-01 9:52 GMT+09:00 Kohei KaiGai kai...@kaigai.gr.jp: 2015-05-01 7:40 GMT+09:00 Alvaro Herrera alvhe...@2ndquadrant.com: Kouhei Kaigai wrote: * Tom Lane (t...@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 kai...@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
Re: [HACKERS] One question about security label command
On Sun, May 10, 2015 at 3:15 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote: 2015-05-01 9:52 GMT+09:00 Kohei KaiGai kai...@kaigai.gr.jp: 2015-05-01 7:40 GMT+09:00 Alvaro Herrera alvhe...@2ndquadrant.com: Kouhei Kaigai wrote: * Tom Lane (t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] One question about security label command
Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: Stephen Frost wrote: * Alvaro Herrera (alvhe...@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 signature.asc Description: Digital signature
Re: [HACKERS] One question about security label command
2015-05-01 7:40 GMT+09:00 Alvaro Herrera alvhe...@2ndquadrant.com: Kouhei Kaigai wrote: * Tom Lane (t...@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 kai...@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
Re: [HACKERS] One question about security label command
Kouhei Kaigai wrote: * Tom Lane (t...@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 Herrerahttp://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
Re: [HACKERS] One question about security label command
Stephen Frost wrote: Hi, * Alvaro Herrera (alvhe...@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 Herrerahttp://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
Re: [HACKERS] One question about security label command
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.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/contrib/sepgsql/expected/label.out b/contrib/sepgsql/expected/label.out
new file mode 100644
index 9d1f904..d41eb48
*** a/contrib/sepgsql/expected/label.out
--- b/contrib/sepgsql/expected/label.out
*** SELECT objtype, objname, label FROM pg_s
*** 82,106
(3 rows)
SELECT objtype, objname, label FROM pg_seclabels
! WHERE provider = 'selinux' AND objtype = 'column' AND (objname like 't3.%' OR objname like 't4.%');
objtype | objname | label
-+-+---
- column | t3.t| unconfined_u:object_r:user_sepgsql_table_t:s0
- column | t3.s| unconfined_u:object_r:user_sepgsql_table_t:s0
- column | t3.ctid | unconfined_u:object_r:user_sepgsql_table_t:s0
- column | t3.xmin | unconfined_u:object_r:user_sepgsql_table_t:s0
- column | t3.cmin | unconfined_u:object_r:user_sepgsql_table_t:s0
- column | t3.xmax | unconfined_u:object_r:user_sepgsql_table_t:s0
column | t3.cmax | unconfined_u:object_r:user_sepgsql_table_t:s0
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)
--
--- 82,107
(3 rows)
SELECT objtype, objname, label FROM pg_seclabels
! WHERE provider = 'selinux' AND objtype = 'column' AND (objname like 't3.%' OR objname like 't4.%')
! ORDER BY objname ASC;
objtype | objname | label
-+-+---
column | t3.cmax | unconfined_u:object_r:user_sepgsql_table_t:s0
+ column | t3.cmin | unconfined_u:object_r:user_sepgsql_table_t:s0
+ column | t3.ctid | unconfined_u:object_r:user_sepgsql_table_t:s0
+ column | t3.s| unconfined_u:object_r:user_sepgsql_table_t:s0
+ column | t3.t| unconfined_u:object_r:user_sepgsql_table_t:s0
column | t3.tableoid | unconfined_u:object_r:user_sepgsql_table_t:s0
! column | t3.xmax | unconfined_u:object_r:user_sepgsql_table_t:s0
! column | t3.xmin | unconfined_u:object_r:user_sepgsql_table_t:s0
column | t4.cmax | unconfined_u:object_r:sepgsql_sysobj_t:s0
+ column | t4.cmin | unconfined_u:object_r:sepgsql_sysobj_t:s0
+ column | t4.ctid | unconfined_u:object_r:sepgsql_sysobj_t:s0
+ column | t4.m| unconfined_u:object_r:sepgsql_table_t:s0
+ column | t4.n| unconfined_u:object_r:sepgsql_table_t:s0
column | t4.tableoid | unconfined_u:object_r:sepgsql_sysobj_t:s0
+ column | t4.xmax | unconfined_u:object_r:sepgsql_sysobj_t:s0
+ column | t4.xmin | unconfined_u:object_r:sepgsql_sysobj_t:s0
(16 rows)
--
diff --git a/contrib/sepgsql/sql/label.sql b/contrib/sepgsql/sql/label.sql
new file mode 100644
index 7a05c24..f4d50c3
*** a/contrib/sepgsql/sql/label.sql
--- b/contrib/sepgsql/sql/label.sql
*** INSERT INTO t4 VALUES (1,'mmm'), (2,'nnn
*** 78,84
SELECT objtype, objname, label FROM pg_seclabels
WHERE provider = 'selinux' AND objtype = 'table' AND objname in ('t1', 't2', 't3');
SELECT objtype, objname, label FROM pg_seclabels
! WHERE provider = 'selinux' AND objtype = 'column' AND (objname like 't3.%' OR objname like 't4.%');
--
-- Tests for SECURITY LABEL
--- 78,85
SELECT objtype, objname, label FROM pg_seclabels
WHERE provider = 'selinux' AND objtype = 'table' AND objname in ('t1', 't2', 't3');
SELECT objtype, objname, label FROM pg_seclabels
! WHERE provider = 'selinux' AND objtype = 'column' AND (objname like 't3.%' OR
Re: [HACKERS] One question about security label command
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 Herrerahttp://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
Re: [HACKERS] One question about security label command
Alvaro, KaiGai, * Alvaro Herrera (alvhe...@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 signature.asc Description: Digital signature
Re: [HACKERS] One question about security label command
Tom, * Tom Lane (t...@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 signature.asc Description: Digital signature
Re: [HACKERS] One question about security label command
Stephen Frost sfr...@snowman.net writes: * Alvaro Herrera (alvhe...@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
Re: [HACKERS] One question about security label command
* Tom Lane (t...@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 kai...@ak.jp.nec.com -Original Message- From: Stephen Frost [mailto:sfr...@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 (t...@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
Re: [HACKERS] One question about security label command
On Tue, Mar 10, 2015 at 6:58 PM, Kohei KaiGai kai...@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 regression.diffs Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] One question about security label command
2015-03-12 1:27 GMT+09:00 Alvaro Herrera alvhe...@2ndquadrant.com: Robert Haas wrote: On Tue, Mar 10, 2015 at 6:58 PM, Kohei KaiGai kai...@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 kai...@kaigai.gr.jp sepgsql-fixup-regtest-policy.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] One question about security label command
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 Herrerahttp://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
Re: [HACKERS] One question about security label command
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 robertmh...@gmail.com: On Tue, Mar 3, 2015 at 5:01 AM, Kouhei Kaigai kai...@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 kai...@kaigai.gr.jp security-label-errmsg.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] One question about security label command
On Tue, Mar 10, 2015 at 9:41 AM, Alvaro Herrera alvhe...@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
Re: [HACKERS] One question about security label command
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 robertmh...@gmail.com: On Tue, Mar 10, 2015 at 9:41 AM, Alvaro Herrera alvhe...@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 kai...@kaigai.gr.jp security-label-errmsg.v2.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] One question about security label command
On Tue, Mar 3, 2015 at 5:01 AM, Kouhei Kaigai kai...@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
Re: [HACKERS] 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 kai...@ak.jp.nec.com
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@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
[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.
