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
