Re: [PATCH] DefaultACLs - Mailing list pgsql-hackers

From KaiGai Kohei
Subject Re: [PATCH] DefaultACLs
Date
Msg-id 4ACBF2CC.5050506@ak.jp.nec.com
Whole thread Raw
In response to Re: [PATCH] DefaultACLs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Petr Jelinek <pjmodos@pjmodos.net> writes:
>> KaiGai Kohei napsal(a):
>>> SELECT INTO does not check ACL_INSERT on the newly created tables, because
>>> we had been able to assume the table owner always has privilege to insert
>>> values into the new table.
>>> So, OpenIntoRel() didn't check this obvious privilege.
>>>
>>> But the default ACL feature breaks this assumption. The table owner may not
>>> have privilege to insert values into new tables.
>>> So, it is necessary to put actual access controls on the OpenIntoRel().
> 
>> That's strange behavior I agree. However I don't see how default ACLs
>> changed it in any way, owner could REVOKE his privileges before.
> 
> The point is that some rows got into the new table, which should have
> been disallowed if CREATE TABLE AS is considered to represent a CREATE
> followed by an INSERT.  However, I disagree that this necessarily
> represents a bug in the permissions checks.  We could perfectly well
> define that INSERT means the right to insert into the table *after it is
> created*, and that CREATE TABLE AS does not involve this right.  I think
> that that is a reasonable and potentially useful thing to do, whereas
> defining it as KaiGai-san suggests would have no usefulness whatsoever.
> What's more, CREATE TABLE AS is specified in the SQL standard, and I see
> nothing in the standard mentioning that it requires INSERT privilege.

It is also an issue due to the differences in perspectives and security models.

My major concern is come from the viewpoint of MAC which tries to control
data flows based on sensitivity levels.
So, if the default PG model considers that "CREATE TABLE AS" is an atomic
operation, not a pair of CREATE and INSERTs, I think it is an approach to
understand this behavior.
In my preference, this perspective should be documented somewhere.
(source code comments or official documentation?)

BTW, in the MAC model, we must strictly prevent a user with classified
security level to write any data into objects with unclassified security
level. It is called "write-down", being equivalent to information leaks.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Streaming Replication patch for CommitFest 2009-09
Next
From: Emmanuel Cecchet
Date:
Subject: Re: COPY enhancements