Greetings,
* Kohei KaiGai (kaigai@heterodb.com) wrote:
> 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?
> 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?
There's been much discussion and justifcation for adding an independent
TRUNCATE privilege to GRANT (which actually took many years to be
allowed). I don't see why we wouldn't represent that as a different
privilege to external MAC systems. If the external MAC system wishes to
use db_table:{delete} to decide if the privilege is allowed or not, they
can, but I don't think core should force that when we have them as
independent permissions.
So, perhaps we can argue about what the sepgsql extension should do, but
it's clear that we should have an independent hook for this in core.
Isn't there a way to allow an admin to control if db_table:{truncate} is
allowed for users with db_table:{delete}, or not? Ideally, this could
be managed at the SELinux level instead of having to have something
different in sepgsql or core, but if it needs to be configurable there
too then hopefully we can come up with a good solution.
Thanks,
Stephen