Re: contrib/sepgsql regression tests are a no-go

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: contrib/sepgsql regression tests are a no-go
Дата
Msg-id CA+TgmobPquFcdU69-oTu3O+BUxgmcwRU=szfu1ATUhuBqe3uZA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: contrib/sepgsql regression tests are a no-go  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: contrib/sepgsql regression tests are a no-go
Список pgsql-hackers
On Mon, Sep 26, 2011 at 11:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Another possibility is to remove the Makefile's knowledge of how to run
>>> the tests, and change chkselinuxenv into something that both verifies
>>> the environment and then launches the tests.
>
>> That's not a bad fix, either.
>
>> I have my doubts about the theory that we'll ever be able to make
>> these regression tests work without some kind of support within the
>> system security policy.  The whole point of MAC, for better or for
>> worse, is to make every decision to allow access made anywhere in the
>> system subject to veto by the system security policy.  I'd certainly
>> be happy to find out that there's a way to make it work the way you're
>> hoping, but I'm not expecting it.  Now maybe you'll say that we should
>> then remove the regression tests altogether, but I don't think that
>> having no regression tests is better than having regression tests that
>> are a pain-in-the-tail to run and most people won't.
>
> The main point I'm on about here is that "make check" must not require
> root privileges.  That is absolutely not negotiable (even if it were
> sane from a security standpoint, which is ridiculous anyway).  I don't
> think "make installcheck" should require root either, although there
> might possibly be a little more wiggle room there.  If it's infeasible
> to test sepgsql usefully without root involvement, then it can't be
> tested within the existing regression test framework.  So maybe just
> pushing the issue out to a separate shell script that you can choose
> to invoke by hand is a reasonable compromise.
>
> I think it should be possible to still use all the existing testing
> infrastructure if the check/test script does something like
>        make REGRESS="label dml misc" check
>
> BTW, I think this line of argument also casts serious doubt on whether
> REGRESS_PREP is a useful concept at all.  I'm more than half tempted to
> revert the patches that added that to the regression test
> infrastructure.  Do we still need the --launcher option, either?

I want to be able to run these tests, but I'm not fussy about the
exact mechanism.  If you want to whack it around so that I type
"./funky_sepgsql_regression_crap" instead of "make installcheck",
that's fine with me.  And if that means you can rip out some
supporting infrastructure, that's fine too.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Support UTF-8 files with BOM in COPY FROM
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Multixact truncation for FK locks patch