Re: add a MAC check for TRUNCATE

From: Kohei KaiGai <kaigai(at)heterodb(dot)com>
To: Yuli Khodorkovskiy <yuli(dot)khodorkovskiy(at)crunchydata(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: add a MAC check for TRUNCATE
Date: 2019-09-02 14:58:08
Message-ID: CAOP8fzbfhrbfv-7+N8YvPxEsvKF1oxg8QNaJCmPg=g1NQ6uJTA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Yuli,

2019年7月25日(木) 3:52 Yuli Khodorkovskiy <yuli(dot)khodorkovskiy(at)crunchydata(dot)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?
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?

Best regards,
--
HeteroDB, Inc / The PG-Strom Project
KaiGai Kohei <kaigai(at)heterodb(dot)com>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2019-09-02 15:37:52 Re: Problem while updating a foreign table pointing to a partitioned table on foreign server
Previous Message Tom Lane 2019-09-02 14:55:01 Re: pg_dump --exclude-* options documentation