Re: sepgsql seems rather thoroughly broken on Fedora 30

From: Mike Palmiotto <mike(dot)palmiotto(at)crunchydata(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: sepgsql seems rather thoroughly broken on Fedora 30
Date: 2019-07-19 20:49:44
Message-ID: CAMN686F+tpUUW1B=9nF-CiNRrEByBPmK-k2Qwp+Fh8G+EVMhug@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 19, 2019 at 4:29 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Mike Palmiotto <mike(dot)palmiotto(at)crunchydata(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2019-07-19 20:50:56 Re: minimizing pg_stat_statements performance overhead
Previous Message Tom Lane 2019-07-19 20:29:25 Re: sepgsql seems rather thoroughly broken on Fedora 30