Feedback-ID: ia2694551:Fastmail
Date: Tue, 5 Sep 2023 19:44:44 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Pg Hackers <pgsql-hackers@lists.postgresql.org>
Subject: missing privilege check after not-null constraint rework
Message-ID: <202309051744.y4mndw5gwzhh@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/202309051744.y4mndw5gwzhh%40alvherre.pgsql>
Precedence: bulk

Here's a fix to move the privilege check on constraint dropping from
ATExecDropConstraint to dropconstraint_internal.  The former doesn't
recurse anymore, so there's no point in doing that or in fact even
having the 'recursing' argument anymore.

This fixes the following test case

CREATE ROLE alice;
CREATE ROLE bob;

GRANT ALL ON SCHEMA PUBLIC to alice, bob;
GRANT alice TO bob;

SET ROLE alice;
CREATE TABLE parent (a int NOT NULL);

SET ROLE bob;
CREATE TABLE child () INHERITS (parent);

At this point, bob owns the child table, to which alice has no access.
But alice can do this:
ALTER TABLE parent ALTER a DROP NOT NULL;
which is undesirable, because it removes the NOT NULL constraint from
table child, which is owned by bob.


Alternatively, we could say that Alice is allowed to drop the constraint
on her table, and that we should react by marking the constraint on
Bob's child table as 'islocal' instead of removing it.  Now, I'm pretty
sure we don't really care one bit about this case, and the reason is
this: we seem to have no tests for mixed-ownership table hierarchies.
If we did care, we would have some, and this bug would not have occurred
in the first place.  Besides, nobody likes legacy inheritance anyway.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"La persona que no quería pecar / estaba obligada a sentarse
 en duras y empinadas sillas    / desprovistas, por cierto
 de blandos atenuantes"                          (Patricio Vogel)