Re: add a MAC check for TRUNCATE - Mailing list pgsql-hackers

From Yuli Khodorkovskiy
Subject Re: add a MAC check for TRUNCATE
Date
Msg-id CAFL5wJdn_X7BgJTw253egmZ5dcne9Y3ttPHf9SMr1pJdrqOCNA@mail.gmail.com
Whole thread Raw
In response to Re: add a MAC check for TRUNCATE  (Kohei KaiGai <kaigai@heterodb.com>)
List pgsql-hackers
On Mon, Sep 2, 2019 at 10:58 AM Kohei KaiGai <kaigai@heterodb.com> wrote:
>
> Hello Yuli,

Hello KaiGai,

>
> 2019年7月25日(木) 3:52 Yuli Khodorkovskiy <yuli.khodorkovskiy@crunchydata.com>:
> > Since all DAC checks should have corresponding MAC, this patch adds a
> > hook to allow extensions to implement a MAC check on TRUNCATE. I have
> > also implemented this access check in the sepgsql extension.
> >
> > One important thing to note is that refpolicy [1] and Redhat based
> > distributions do not have the SELinux permission for db_table {truncate}
> > implemented.
> >
> How db_table:{delete} permission is different from truncate?
> From the standpoint of data access, TRUNCATE is equivalent to DELETE
> without WHERE, isn't it?

To echo Stephen's reply, since TRUNCATE has a dedicated privilege in
the GRANT system, there should be a MAC based permission as well.
Increased granularity for an integrator to add least privileged policy
is a good idea in my view.

> Of course, there are some differences between them. TRUNCATE takes
> exclusive locks and eliminates underlying data blocks, on the other hands,
> DELETE removes rows under MVCC manner. However, both of them
> eventually removes data from the target table.
>
> I like to recommend to reuse "db_table:{delete}" permission for TRUNCATE.
> How about your opinions?

Now that I think about it, using "db_table { delete }" would be fine,
and that would remove the CIL requirement that I stated earlier. Thank
you for the suggestion. I'll send a v2 patch using the delete
permission.

Thank you,

Yuli


>
> Best regards,
> --
> HeteroDB, Inc / The PG-Strom Project
> KaiGai Kohei <kaigai@heterodb.com>



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: tableam vs. TOAST
Next
From: Tom Lane
Date:
Subject: Re: tableam vs. TOAST