Re: add a MAC check for TRUNCATE - Mailing list pgsql-hackers

From Tom Lane
Subject Re: add a MAC check for TRUNCATE
Date
Msg-id 1757.1567785426@sss.pgh.pa.us
Whole thread Raw
In response to Re: add a MAC check for TRUNCATE  (Stephen Frost <sfrost@snowman.net>)
Responses Re: add a MAC check for TRUNCATE
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Yuli Khodorkovskiy <yuli.khodorkovskiy@crunchydata.com> writes:
>>> 1) Get the sepgsql changes in without policy/regressions
>>> 2) Send a patch to refpolicy for the new permission
>>> 3) Once Redhat updates the selinux-policy-targeted RPM to include the
>>> new permissions, I will send an update to the sepgsql regressions and
>>> policy.

>> That's going to be a problem.  I do not think it will be acceptable
>> to commit tests that fail on less-than-bleeding-edge SELinux.

> This is why I was suggesting up-thread that it'd be neat if we made this
> somehow optional, though I don't quite see a way to do that sensibly.
> We could though, of course, make running the regression test optional
> and then have a buildfarm member that's got the bleeding-edge SELinux
> (or is just configured with the additional control) and then have it
> enabled there.

Well, the larger question, independent of the regression tests, is
will the new policy work at all on older SELinux?  If not, that
doesn't seem very acceptable.  Worse, it implies we're going to
have another flag day anytime we want to add any new element
to sepgsql's view of the universe.  I think we need some hard
thought about upgrade paths here --- at least, if we want to
believe that sepgsql is anything but a toy for demonstration
purposes.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Yuli Khodorkovskiy
Date:
Subject: Re: add a MAC check for TRUNCATE
Next
From: Konstantin Knizhnik
Date:
Subject: Re: Built-in connection pooler