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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: contrib/sepgsql regression tests are a no-go
Date: 2011-09-26 16:12:38
Message-ID: CA+TgmobPquFcdU69-oTu3O+BUxgmcwRU=szfu1ATUhuBqe3uZA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 26, 2011 at 11:03 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2011-09-26 16:16:24 Multixact truncation for FK locks patch
Previous Message Robert Haas 2011-09-26 16:07:26 Re: Support UTF-8 files with BOM in COPY FROM