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

2011-10-01 Thread Joshua Brindle

Robert Haas wrote:

On Tue, Sep 27, 2011 at 6:30 PM, Tom Lanet...@sss.pgh.pa.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.



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-27 Thread Kohei KaiGai
2011/9/26 Tom Lane t...@sss.pgh.pa.us:
 Kohei KaiGai kai...@kaigai.gr.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 kai...@kaigai.gr.jp

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-27 Thread Tom Lane
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

diff --git a/contrib/sepgsql/Makefile b/contrib/sepgsql/Makefile
index 033c41a..140419a 100644
*** a/contrib/sepgsql/Makefile
--- b/contrib/sepgsql/Makefile
*** OBJS = hooks.o selinux.o uavc.o label.o 
*** 5,15 
  	database.o schema.o relation.o proc.o
  DATA_built = sepgsql.sql
  
! REGRESS = label dml misc
! REGRESS_PREP = check_selinux_environment
! REGRESS_OPTS = --launcher $(top_builddir)/contrib/sepgsql/launcher
! 
! EXTRA_CLEAN = -r tmp *.pp sepgsql-regtest.if sepgsql-regtest.fc
  
  ifdef USE_PGXS
  PG_CONFIG = pg_config
--- 5,13 
  	database.o schema.o relation.o proc.o
  DATA_built = sepgsql.sql
  
! # Note: because we don't tell the Makefile there are any regression tests,
! # we have to clean those result files explicitly
! EXTRA_CLEAN = -r $(pg_regress_clean_files) tmp *.pp sepgsql-regtest.if sepgsql-regtest.fc
  
  ifdef USE_PGXS
  PG_CONFIG = pg_config
*** include $(top_srcdir)/contrib/contrib-gl
*** 23,28 
  endif
  
  SHLIB_LINK += -lselinux
- 
- check_selinux_environment:
- 	@$(top_builddir)/contrib/sepgsql/chkselinuxenv $(bindir) $(datadir)
--- 21,23 
diff --git a/contrib/sepgsql/chkselinuxenv b/contrib/sepgsql/chkselinuxenv
index a7c81b2..2eeeb67 100755
*** a/contrib/sepgsql/chkselinuxenv
--- b/contrib/sepgsql/chkselinuxenv
***
*** 1,11 
  #!/bin/sh
  #
! # SELinux environment checks to ensure configuration of the operating system
! # satisfies prerequisites to run regression test.
! # If incorrect settings are found, this script suggest user a hint.
  #
! PG_BINDIR=$1
! PG_DATADIR=$2
  
  echo
  echo == checking selinux environment   ==
--- 1,18 
  #!/bin/sh
  #
! # Run the sepgsql regression tests, after making a lot of environmental checks
! # to try to ensure that the SELinux environment is set up appropriately and
! # the database is configured correctly.
  #
! # Note that this must be run against an installed Postgres database.
! # There's no equivalent of make check, and that wouldn't be terribly useful
! # since much of the value is in checking that you installed sepgsql into
! # your database correctly.
! #
! # This must be run in the contrib/sepgsql directory of a Postgres build tree.
! #
! 
! PG_BINDIR=`pg_config --bindir`
  
  echo
  echo == checking selinux environment   ==
*** fi
*** 224,230 
  echo found ${NUM}
  
  #
! # check complete - 
  #
! echo 
! exit 0
--- 231,242 
  echo found ${NUM}
  
  #
! # checking complete - let's run the tests
  #
! 
! echo
! echo == running sepgsql regression tests   ==
! 
! make REGRESS=label dml misc REGRESS_OPTS=--launcher ./launcher installcheck
! 
! # exit with the exit code provided by make

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-27 Thread Robert Haas
On Tue, Sep 27, 2011 at 3:39 PM, Tom Lane t...@sss.pgh.pa.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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-27 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 On Tue, Sep 27, 2011 at 3:39 PM, Tom Lane t...@sss.pgh.pa.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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-27 Thread Robert Haas
On Tue, Sep 27, 2011 at 6:30 PM, Tom Lane t...@sss.pgh.pa.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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-26 Thread Kohei KaiGai
2011/9/26 Tom Lane t...@sss.pgh.pa.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 kai...@kaigai.gr.jp

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-26 Thread Peter Eisentraut
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.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-26 Thread Tom Lane
Peter Eisentraut pete...@gmx.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.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-26 Thread Robert Haas
On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Peter Eisentraut pete...@gmx.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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-26 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane t...@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?

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-26 Thread Kohei KaiGai
2011/9/26 Tom Lane t...@sss.pgh.pa.us:
 Robert Haas robertmh...@gmail.com writes:
 On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane t...@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.

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 kai...@kaigai.gr.jp

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-26 Thread Robert Haas
On Mon, Sep 26, 2011 at 11:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.com writes:
 On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane t...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-26 Thread Kohei KaiGai
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 robertmh...@gmail.com:
 On Mon, Sep 26, 2011 at 11:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.com writes:
 On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane t...@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




-- 
KaiGai Kohei kai...@kaigai.gr.jp


sepgsql-fix-regtest.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-26 Thread Tom Lane
Kohei KaiGai kai...@kaigai.gr.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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] contrib/sepgsql regression tests are a no-go

2011-09-25 Thread Tom Lane
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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-25 Thread Robert Haas
On Sun, Sep 25, 2011 at 9:07 PM, Tom Lane t...@sss.pgh.pa.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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-25 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 On Sun, Sep 25, 2011 at 9:07 PM, Tom Lane t...@sss.pgh.pa.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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


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

2011-09-25 Thread Robert Haas
On Mon, Sep 26, 2011 at 12:06 AM, Tom Lane t...@sss.pgh.pa.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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers