Обсуждение: 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@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
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Sep 25, 2011 at 9:07 PM, Tom Lane <tgl@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
On Mon, Sep 26, 2011 at 12:06 AM, Tom Lane <tgl@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
2011/9/26 Tom Lane <tgl@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 <kaigai@kaigai.gr.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@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
On Mon, Sep 26, 2011 at 10:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@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
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 likemake 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@sss.pgh.pa.us>: > 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. > 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@kaigai.gr.jp>
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
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@gmail.com>: > 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 > -- KaiGai Kohei <kaigai@kaigai.gr.jp>
Вложения
Kohei KaiGai <kaigai@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
2011/9/26 Tom Lane <tgl@sss.pgh.pa.us>: > Kohei KaiGai <kaigai@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 <kaigai@kaigai.gr.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
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"
On Tue, Sep 27, 2011 at 3:39 PM, Tom Lane <tgl@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
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Sep 27, 2011 at 3:39 PM, Tom Lane <tgl@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
On Tue, Sep 27, 2011 at 6:30 PM, Tom Lane <tgl@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
Robert Haas wrote: > On Tue, Sep 27, 2011 at 6:30 PM, Tom Lane<tgl@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.