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

So I thought it would be a good idea to enable contrib/sepgsql in the
Fedora build of 9.1. This soon crashed and burned, though, because

(1) if you build sepgsql, there is no way to omit the sepgsql regression
tests, other than by not regression-testing contrib at all. I didn't
see that as a step forward.

(2) the sepgsql regression tests cannot be run without having done
assorted root-privilege-required tweaks to the SELinux configuration.
RPMs are not customarily built with root privilege, and even if they
were, having one fool with the SELinux configuration like that would
set off alarm bells for a lot of people.

In particular, point (2) means that "make check" is a joke. You can't
do it without serious side-effects on the state of the host system,
which is contrary to the entire purpose of that make target.

I am of the opinion that these regression tests need to be reworked
so that they do not require a nonstandard SELinux environment.
I realize however that that's likely to take nontrivial work.
As a stopgap, what about removing sepgsql from the list of contrib
modules tested by "make -C contrib check"? (I haven't looked at
exactly how ugly it might be to do that, nor whether we'd have to also
disable installcheck from recursing to sepgsql.)

regards, tom lane

On Sun, Sep 25, 2011 at 9:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> As a stopgap, what about removing sepgsql from the list of contrib
> modules tested by "make -C contrib check"?

+1.

In fact, I've been wondering if we ought to go a step further and not
recurse into the sepgsql directory for *any* of the targets. Then we
could get rid of the associated configure option, which no longer
serves any other purpose, and just say that if you want to build (or
regression-test) sepgsql, well, you gotta go to that directory and do
it by hand.

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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Sep 25, 2011 at 9:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> As a stopgap, what about removing sepgsql from the list of contrib
>> modules tested by "make -C contrib check"?

> +1.

> In fact, I've been wondering if we ought to go a step further and not
> recurse into the sepgsql directory for *any* of the targets.

Hmm. That would be a lot cleaner than the alternatives I've thought
of so far for recursing for only some targets.

> Then we
> could get rid of the associated configure option, which no longer
> serves any other purpose, and just say that if you want to build (or
> regression-test) sepgsql, well, you gotta go to that directory and do
> it by hand.

The trouble with getting rid of configure support is that we lose the
opportunity to verify that you have a new-enough version of libselinux.
That's maybe not a big deal, but it's a point worth noting.

regards, tom lane

On Mon, Sep 26, 2011 at 12:06 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Then we
>> could get rid of the associated configure option, which no longer
>> serves any other purpose, and just say that if you want to build (or
>> regression-test) sepgsql, well, you gotta go to that directory and do
>> it by hand.
>
> The trouble with getting rid of configure support is that we lose the
> opportunity to verify that you have a new-enough version of libselinux.
> That's maybe not a big deal, but it's a point worth noting.

I suppose the main downside there is that you will get a more cryptic
error message if it isn't new enough.

On the other hand, even if you don't use --with-selinux, you can still
do "make -C contrib/sepgsql" and you'll have the same problem, so I'm
not sure that we're really heavily shielded against a failure of this
type as it is.

Perhaps we could remove --with-selinux, but *always* test whether we
have a new enough version of selinux. If we don't, we set it up so
that configure succeeds anyway, but any attempt to build sepgsql
fails? (Not sure if there's a clean way to do that.)

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

2011/9/26 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> As a stopgap, what about removing sepgsql from the list of contrib
> modules tested by "make -C contrib check"?  (I haven't looked at
> exactly how ugly it might be to do that, nor whether we'd have to also
> disable installcheck from recursing to sepgsql.)
>
Is it unavailable to provide a hint to inform the main Makefile this contrib
module does not support either make 'check' or 'installcheck'?

For example, How about an idea to add REGRESS_AVAILABLE that
takes empty, 'only-check' or 'only-checkinstall'; and skip regression test
when 'only-checkinstall' is set on this?
If so, we shall handle similar cases in the future; without trade-off.

I also think it is not a reasonable option to remove --with-selinux to restain
regression test, instead of libselinux version checks.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

On sön, 2011-09-25 at 23:49 -0400, Robert Haas wrote:
> In fact, I've been wondering if we ought to go a step further and not
> recurse into the sepgsql directory for *any* of the targets. Then we
> could get rid of the associated configure option, which no longer
> serves any other purpose, and just say that if you want to build (or
> regression-test) sepgsql, well, you gotta go to that directory and do
> it by hand.

I'm not in favor of that. It's nice to have a uniform interface that
decides what to build.

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On sn, 2011-09-25 at 23:49 -0400, Robert Haas wrote:
>> In fact, I've been wondering if we ought to go a step further and not
>> recurse into the sepgsql directory for *any* of the targets. Then we
>> could get rid of the associated configure option, which no longer
>> serves any other purpose, and just say that if you want to build (or
>> regression-test) sepgsql, well, you gotta go to that directory and do
>> it by hand.

> I'm not in favor of that. It's nice to have a uniform interface that
> decides what to build.

Well, the right fix is to fix the sepgsql regression tests so that they
adhere to the uniform model of being something you can run without
destructive modifications to the host system. What's being discussed at
the moment is the least messy stopgap we can have until the tests are
fixed. I think that just taking sepgsql out of the subdirectory list
(except for "make clean") might well be the most attractive workaround.

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.

regards, tom lane

On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On sön, 2011-09-25 at 23:49 -0400, Robert Haas wrote:
>>> In fact, I've been wondering if we ought to go a step further and not
>>> recurse into the sepgsql directory for *any* of the targets.  Then we
>>> could get rid of the associated configure option, which no longer
>>> serves any other purpose, and just say that if you want to build (or
>>> regression-test) sepgsql, well, you gotta go to that directory and do
>>> it by hand.
>
>> I'm not in favor of that.  It's nice to have a uniform interface that
>> decides what to build.
>
> Well, the right fix is to fix the sepgsql regression tests so that they
> adhere to the uniform model of being something you can run without
> destructive modifications to the host system.  What's being discussed at
> the moment is the least messy stopgap we can have until the tests are
> fixed.  I think that just taking sepgsql out of the subdirectory list
> (except for "make clean") might well be the most attractive workaround.
>
> 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.

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

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?

regards, tom lane

2011/9/26 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 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.
>
If so, is it an option that contrib/sepgsql/Makefile implement its own
regression test scheme? Even if it requires root/unconfined privilege
to set up test server automatically, it is harmless as long as these
are not launched with regular "make check/installchek".

> 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?
>
If contrib/sepgsql/Makefile implements its own tests including environment
checks, I think REGRESS_PREP is fungible. But --launcher option is necessary
to implement test schemes on the pg_regress.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

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

How about this fix on regression test of sepgsql?

It disables to launch regression test together with other modules,
and adds its own build target "sepgsql-installcheck" that launches
chkselinuxenv script then pg_regress command as currently we
are doing.

It allows users to launch regression test by hand, in same time,
it also enables to build all the contrib modules on the rpm build
environment without selinux ready.

2011/9/26 Robert Haas <robertmhaas(at)gmail(dot)com>:
> 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
>

--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> writes:
> How about this fix on regression test of sepgsql?

IMO, the fundamental problem with the sepgsql regression tests is that
they think they don't need to play by the rules that apply to every
other PG regression test. I don't think this patch is fixing that
problem; it's just coercing pgxs.mk to assist in not playing by the
rules, and adding still more undocumented complexity to the PGXS
mechanisms in order to do so.

If we have to have a nonstandard command for running the sepgsql
regression tests, as it seems that we do, we might as well just make
that an entirely local affair within contrib/sepgsql.

regards, tom lane

2011/9/26 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> writes:
>> How about this fix on regression test of sepgsql?
>
> IMO, the fundamental problem with the sepgsql regression tests is that
> they think they don't need to play by the rules that apply to every
> other PG regression test.  I don't think this patch is fixing that
> problem; it's just coercing pgxs.mk to assist in not playing by the
> rules, and adding still more undocumented complexity to the PGXS
> mechanisms in order to do so.
>
> If we have to have a nonstandard command for running the sepgsql
> regression tests, as it seems that we do, we might as well just make
> that an entirely local affair within contrib/sepgsql.
>
Are you suggesting to make a command/script to check OS environment
and run its own regression test without touching existing pg_regress
framework, even if it just utilizes existing options?
It seems to me re-inventment of a wheel....

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

I wrote:
> 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

I've now worked through the process of actually running the sepgsql
regression tests, and I must say that I had no idea how utterly invasive
they were --- the idea that they could ever be part of a default "make
check" sequence is even more ridiculous than I thought before.

Accordingly, the attached patch does what I suggested above, namely dike
out the Makefile's knowledge of how to run the regression tests and put
it into the chkselinuxenv script. It would be appropriate to rename that
script to something like "test_sepgsql", but I didn't do that yet to
reduce the displayed size of the patch.

I have not touched the documentation, either. One thing I'd like to do
is adjust both the SGML documentation and the hints printed by the
script to uniformly use "sudo ...root-privileged-command..." rather than
recommending use of "su". I don't like the latter because it makes it
less than clear exactly which commands require root, encourages you to
forget to switch out of root mode, and IMO is against local policy on
any well-run box. I recognize however that that might be mostly my
own preferences showing --- what do others think?

Comments?

regards, tom lane

On Tue, Sep 27, 2011 at 3:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
>> 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
>
> I've now worked through the process of actually running the sepgsql
> regression tests, and I must say that I had no idea how utterly invasive
> they were --- the idea that they could ever be part of a default "make
> check" sequence is even more ridiculous than I thought before.
>
> Accordingly, the attached patch does what I suggested above, namely dike
> out the Makefile's knowledge of how to run the regression tests and put
> it into the chkselinuxenv script.  It would be appropriate to rename that
> script to something like "test_sepgsql", but I didn't do that yet to
> reduce the displayed size of the patch.

Seems fine. The rename is definitely needed. We may want to
back-patch this into 9.1 to avoid the headache of dealing with this
for 5 years.

> I have not touched the documentation, either.  One thing I'd like to do
> is adjust both the SGML documentation and the hints printed by the
> script to uniformly use "sudo ...root-privileged-command..." rather than
> recommending use of "su".  I don't like the latter because it makes it
> less than clear exactly which commands require root, encourages you to
> forget to switch out of root mode, and IMO is against local policy on
> any well-run box.  I recognize however that that might be mostly my
> own preferences showing --- what do others think?

I think that's your own preference showing. How about just telling
people to run the commands as root without specifying how they should
accomplish that?

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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Sep 27, 2011 at 3:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Accordingly, the attached patch does what I suggested above, namely dike
>> out the Makefile's knowledge of how to run the regression tests and put
>> it into the chkselinuxenv script.

> Seems fine. The rename is definitely needed. We may want to
> back-patch this into 9.1 to avoid the headache of dealing with this
> for 5 years.

I'm definitely gonna back-patch it, because otherwise I'll be carrying
it as a RHEL and Fedora patch for that long ;-)

>> I have not touched the documentation, either. One thing I'd like to do
>> is adjust both the SGML documentation and the hints printed by the
>> script to uniformly use "sudo ...root-privileged-command..." rather than
>> recommending use of "su".

> I think that's your own preference showing. How about just telling
> people to run the commands as root without specifying how they should
> accomplish that?

Well, maybe, but it seems hard to do without being verbose. If you just
say

$ sudo blah blah blah

the meaning is obvious (or if it isn't, you got no business playing with
SELinux anyway), and you can easily include, or not, the "sudo" part when
copying and pasting the command. Right now we've got things like

$ cd .../contrib/sepgsql
$ make -f /usr/share/selinux/devel/Makefile
$ su
# semodule -u sepgsql-regtest.pp
# semodule -l | grep sepgsql
sepgsql-regtest 1.03

What I'd prefer is

$ cd .../contrib/sepgsql
$ make -f /usr/share/selinux/devel/Makefile
$ sudo semodule -u sepgsql-regtest.pp
$ sudo semodule -l | grep sepgsql
sepgsql-regtest 1.03

If I have to break up the recipe with annotations like "run this part as
root" and then "these commands no longer need root", I don't think
that's going to be an improvement over either of the above.

regards, tom lane

On Tue, Sep 27, 2011 at 6:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I have not touched the documentation, either.  One thing I'd like to do
>>> is adjust both the SGML documentation and the hints printed by the
>>> script to uniformly use "sudo ...root-privileged-command..." rather than
>>> recommending use of "su".
>
>> I think that's your own preference showing.  How about just telling
>> people to run the commands as root without specifying how they should
>> accomplish that?
>
> Well, maybe, but it seems hard to do without being verbose.  If you just
> say
>
>        $ sudo blah blah blah
>
> the meaning is obvious (or if it isn't, you got no business playing with
> SELinux anyway), and you can easily include, or not, the "sudo" part when
> copying and pasting the command.  Right now we've got things like
>
> $ cd .../contrib/sepgsql
> $ make -f /usr/share/selinux/devel/Makefile
> $ su
> # semodule -u sepgsql-regtest.pp
> # semodule -l | grep sepgsql
> sepgsql-regtest 1.03
>
> What I'd prefer is
>
> $ cd .../contrib/sepgsql
> $ make -f /usr/share/selinux/devel/Makefile
> $ sudo semodule -u sepgsql-regtest.pp
> $ sudo semodule -l | grep sepgsql
> sepgsql-regtest 1.03
>
> If I have to break up the recipe with annotations like "run this part as
> root" and then "these commands no longer need root", I don't think
> that's going to be an improvement over either of the above.

Fair enough, I'm not going to get bent out of shape about it. There's
some aesthetic value in the way you're proposing, and anyone who is
doing this ought to know enough to make the details of how you write
it out mostly irrelevant.

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

Robert Haas wrote:
> On Tue, Sep 27, 2011 at 6:30 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
<snip>
>>
>> If I have to break up the recipe with annotations like "run this part as
>> root" and then "these commands no longer need root", I don't think
>> that's going to be an improvement over either of the above.
>
> Fair enough, I'm not going to get bent out of shape about it. There's
> some aesthetic value in the way you're proposing, and anyone who is
> doing this ought to know enough to make the details of how you write
> it out mostly irrelevant.
>

Long term a better option may be to use mocking to test policy
enforcement without modifying the system policy.

I've used test-dept <http://code.google.com/p/test-dept/> on a couple
projects and while it is a huge pain to get up and running it is very
nice for mocking outside code (in this case libselinux calls) and
getting predictable output to test your functionality. It would also let
you run the tests on a non-SELinux system.

There are other c mocking frameworks, this is just the one I have
experience with. test-dept might not be suitable for Postgres because it
uses arch-specific awk scripts to munge symbol tables, and only supports
x86, x86_64 and sparc right now.