Tom Lane wrote: > Petr Jelinek <pjmo...@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 <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
