Re: add a MAC check for TRUNCATE

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: add a MAC check for TRUNCATE
Дата
Msg-id 1757.1567785426@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: add a MAC check for TRUNCATE  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: add a MAC check for TRUNCATE  (Yuli Khodorkovskiy <yuli.khodorkovskiy@crunchydata.com>)
Список 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 по дате отправления:

Предыдущее
От: Yuli Khodorkovskiy
Дата:
Сообщение: Re: add a MAC check for TRUNCATE
Следующее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: Built-in connection pooler