Re: sepgsql seems rather thoroughly broken on Fedora 30 - Mailing list pgsql-hackers

From Mike Palmiotto
Subject Re: sepgsql seems rather thoroughly broken on Fedora 30
Date
Msg-id CAMN686F+tpUUW1B=9nF-CiNRrEByBPmK-k2Qwp+Fh8G+EVMhug@mail.gmail.com
Whole thread Raw
In response to Re: sepgsql seems rather thoroughly broken on Fedora 30  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: sepgsql seems rather thoroughly broken on Fedora 30  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jul 19, 2019 at 4:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Mike Palmiotto <mike.palmiotto@crunchydata.com> writes:
> > We probably need to polish this a bit more, but what do you think
> > about something similar to the attached patches? They should hopefully
> > reduce some of the complexity of running these regression tests.
>
> I can confirm that the 0001 patch fixes things on my Fedora 30 box.
> So that's good, though I don't know enough to evaluate it for style
> or anything like that.

I think the policy is in need of review/rewriting anyway. The proper
thing to do would be to create a common template for all of the
SELinux regtest user domains and create more of a hierarchical policy
to reduce redundancy. If you want to wait for more formal policy
updates, I can do that in my spare time. Otherwise, the patch I posted
should work with the general style of this policy module.

>
> I don't think I like the 0002 patch very much, because of its putting
> all the sudo actions into the script.  I'd rather not give a script
> root permissions, thanks.  Maybe I'm in the minority on that.

Definitely not. I cringed a little bit as I was making those
additions, but figured it was fine since it's just a test script (and
we have to run `sudo` for various other installation items as well).

> Also, since the documentation explicitly says that the
> /usr/share/selinux/devel/Makefile path is not to be relied on,
> why would we hard-wire it into the script?
>
> A bigger-picture issue is that right now, configuring a cluster for
> sepgsql is a very manual process (cf. section F.35.2).  I think there's
> some advantage in forcing the user to run through that before running
> the regression test, namely that they'll get the bugs out of any
> misunderstandings or needed local changes.  If we had that a bit more
> automated then maybe having the test script do-it-for-you would be
> sensible.  (IOW, the fact that the test process is more like "make
> installcheck" than "make check" seems like a feature not a bug.)

Makes sense to me. Thanks for the feedback!

-- 
Mike Palmiotto
Software Engineer
Crunchy Data Solutions
https://crunchydata.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: sepgsql seems rather thoroughly broken on Fedora 30
Next
From: Jeff Davis
Date:
Subject: Re: minimizing pg_stat_statements performance overhead