Re: add a MAC check for TRUNCATE

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Yuli Khodorkovskiy <yuli(dot)khodorkovskiy(at)crunchydata(dot)com>, Kohei KaiGai <kaigai(at)heterodb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: add a MAC check for TRUNCATE
Date: 2019-09-06 15:50:04
Message-ID: 20190906155004.GY16436@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Yuli Khodorkovskiy <yuli(dot)khodorkovskiy(at)crunchydata(dot)com> writes:
> > Ah, now I remember why I didn't add regressions to the original patch.
> > As stated at the top of the thread, the "db_table: { truncate }"
> > permission does not currently exist in refpolicy. A workaround would
> > be to add the policy with CIL, but that adds unneeded complexity to
> > the regressions. I think the correct path forward is:
>
> > 1) Get the sepgsql changes in without policy/regressions
> > 2) Send a patch to refpolicy for the new permission
> > 3) Once Redhat updates the selinux-policy-targeted RPM to include the
> > new permissions, I will send an update to the sepgsql regressions and
> > policy.
>
> That's going to be a problem. I do not think it will be acceptable
> to commit tests that fail on less-than-bleeding-edge SELinux.

This is why I was suggesting up-thread that it'd be neat if we made this
somehow optional, though I don't quite see a way to do that sensibly.

We could though, of course, make running the regression test optional
and then have a buildfarm member that's got the bleeding-edge SELinux
(or is just configured with the additional control) and then have it
enabled there.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yuli Khodorkovskiy 2019-09-06 15:52:32 Re: add a MAC check for TRUNCATE
Previous Message Tom Lane 2019-09-06 15:47:35 Re: add a MAC check for TRUNCATE