From: | Yuli Khodorkovskiy <yuli(dot)khodorkovskiy(at)crunchydata(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | 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 13:51:17 |
Message-ID: | CAFL5wJd_VqLRKVoARzZO=XbHfYckuJPrP1omD=PS_fp+sSpFTw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 3, 2019 at 3:25 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> Greetings,
>
> * Kohei KaiGai (kaigai(at)heterodb(dot)com) wrote:
> > 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?
>
> 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.
If I understand you correctly, you are asking if an SELinux domain can
have the db_table:{truncate} permission but not db_table:{delete}
using SELinux policy? This would only work if the userspace object
manager, sepgsql in this case, reaches out to the policy server to
check if db_table:{truncate} is allowed for a subject accessing an
object.
I think it should be okay to use db_table:{delete} as the permission
to check for TRUNCATE in the object manager. I have attached a second
version of the hook and sepgsql changes to demonstrate this.
Thank you.
>
> Thanks,
>
> Stephen
Attachment | Content-Type | Size |
---|---|---|
Truncate-Hook.patch | application/octet-stream | 3.1 KB |
Sepgsql-Truncate.patch | application/octet-stream | 4.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-09-06 13:56:37 | Re: PostgreSQL 12 Beta 4 |
Previous Message | Alvaro Herrera from 2ndQuadrant | 2019-09-06 13:45:42 | Re: [bug fix] Produce a crash dump before main() on Windows |