Re: sepgsql seems rather thoroughly broken on Fedora 30
От | Mike Palmiotto |
---|---|
Тема | Re: sepgsql seems rather thoroughly broken on Fedora 30 |
Дата | |
Msg-id | CAMN686F+tpUUW1B=9nF-CiNRrEByBPmK-k2Qwp+Fh8G+EVMhug@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: sepgsql seems rather thoroughly broken on Fedora 30 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: sepgsql seems rather thoroughly broken on Fedora 30
|
Список | 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 по дате отправления: