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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
