Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wZj54-001Ezy-14 for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Jun 2026 05:44:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wZj53-004R9O-0v for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Jun 2026 05:44:53 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wZj53-004R9G-00 for pgsql-hackers@lists.postgresql.org; Wed, 17 Jun 2026 05:44:53 +0000 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wZj50-00000000r7r-2NKG for pgsql-hackers@lists.postgresql.org; Wed, 17 Jun 2026 05:44:52 +0000 Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-490b3637b90so41565675e9.3 for ; Tue, 16 Jun 2026 22:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781675089; x=1782279889; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ZXG6JDRKP8Upb5v3rLu6+KpmDH8CkqdFiL4HrgnE2z8=; b=jCZkVnVeJpGDtrUuiSKfdH0Oib5XBxDyXz1AsOE5pSV8ZkB1V9Z0q6w4xl4JWXiUCz nzbMG4cDZvZufR3hfrAXboS4bcD/6deyN0MQgyhlx2bousBnwgyDhU5ZynK1K+I8jC88 6PqDtAI60oKLNhxCe5WV64F19UA7GWAjkRDjOaHpVqhfgpIa3PplZPVlP7MstFJ3dtcz lh6q+9LZHkwMNliIWtUqPLXQdrSAPXOo+bd9yDrKqw6L+j2Bm+cT/WCS0EbPcrLuwc/M Xd//Sna7XqzGbrjPe4rWak+4QLYbLPIMCC4BcUh24jraLvjNScaNTpP9vRHhal51461Y D4Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781675089; x=1782279889; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZXG6JDRKP8Upb5v3rLu6+KpmDH8CkqdFiL4HrgnE2z8=; b=Vxm1jJ4qoqOjlY6s+RiE98j+DC9GnvWtOHBSOFSUvV43bW3FB9xsHVo+pRw7JHjFYE oPQzFgp1dzr5oeERnHXVUEcm8km9MzPabG1dylZJmBeIUIklS9lHNoDO4ImEdiRI707B xTWNPv1ceaLyj+awW6haY+RC3llVvuwWaATg7JKPv5d5bT4N0rGlpRX98pnE0Qj4SBty 8LyOK9H2vGOyizf8ak9fZYh2hsZoVXhHOXoCJ5NQ13wSC0vNsxq2hBAmtEKNodstKEI7 ru3cdwlIXGd2HPjhqfVYK0S88TOsJquzvXI6zSeGZLjhj/WOMeXqJcg4ylESVKXB+TFe xvtQ== X-Forwarded-Encrypted: i=1; AFNElJ/YWT3eyS21ahtzdkiH4Nepp8EGU3Rop3VIek0j94YyboXl5jRpZ9gDgSCsESQUMT3FBgd+11ND/iQDgrcC@lists.postgresql.org X-Gm-Message-State: AOJu0YypuWh5FgnwhBZe3QbqWDPVMI2S4863H6Zi9j8gr50FTR3wKhDL QtWecgbno1nLu14BIGWE0EOAs0NXUh0/4kxA8WnbRubJFWqJGhonyFbn X-Gm-Gg: Acq92OFJHAm4vebkHVipawUj+xJygkSi+/FWV3swcN5Xu0zBROq6xPpwkE3gJAylFH4 8V4O0IpBJmx9nDNqgYo4zkX+nUwfYVyPK1wHouBHsrZWOeIEYQNUR65DcIYMjljzMUpAO6M5488 jEseu3opWf+QCe9YjQfp1TlNuONeU0VUrgC9EqNmqjV3QimN7tnMPrSGeSD3D1MuBw/AkIDzrSI fj0pHujYXn0NhsKyV1Dd/kURtI68v9sRrZPUQjuBoimLVFwMaddE7n9WgJk9buNS2DvgVF37GNE FNsw1d3u8jNjIOHVszIOWfshoGDal2CoiNZEmOv7nWVTkgL+kllkcT4w9PKn3crV3Pz7icqSOcD /so/L78SoQ+xn6ZSqq9yiEX4MER33WHnjoYupUuI9aPErgmIY5e6qMzFBpPVYRE4dz6sMt10zVJ EZKX+Zgi8fWaUDIUJ1jVNZua1//33QN9gnBAQHsvWV2T8AQRZStskh9J7BxWbSxt6cKrM5X8iV X-Received: by 2002:a05:600c:19cb:b0:48a:8b02:ae91 with SMTP id 5b1f17b1804b1-492333a7639mr36691095e9.11.1781675088876; Tue, 16 Jun 2026 22:44:48 -0700 (PDT) Received: from bdtpg (ec2-15-237-197-144.eu-west-3.compute.amazonaws.com. [15.237.197.144]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49230a96d14sm113719635e9.12.2026.06.16.22.44.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2026 22:44:48 -0700 (PDT) Date: Wed, 17 Jun 2026 05:44:47 +0000 From: Bertrand Drouvot To: Jeff Davis Cc: Heikki Linnakangas , Robert Haas , Roman Eskin , Michael Paquier , Alexander Lakhin , pgsql-hackers@lists.postgresql.org, Tom Lane Subject: Re: Avoid orphaned objects dependencies, take 3 Message-ID: References: <02e28438bd448ff4ee8f6fd78e6b74e657172d73.camel@j-davis.com> <71eb9a8835a28165939da567a9d649fe6d21bfa7.camel@j-davis.com> <0fc145b9b5cf3f59207cf4ca60270448a2891c46.camel@j-davis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On Tue, Jun 16, 2026 at 12:14:12PM -0700, Jeff Davis wrote: > On Tue, 2026-06-16 at 10:09 +0000, Bertrand Drouvot wrote: > > 0002: fixes it by moving aclcheck_track_record() to after the > > permission check > > succeeds in object_aclcheck_ext() and pg_class_aclcheck_ext(). > > Indeed, there is > > no need to track failed permission checks. > > IIUC, this is necessary for correctness. If an ACL failure doesn't > cause a transaction abort, then there's a danger that we cause the > transaction to fail that should have succeeded. Exactly, because we'd recheck an "harmless" failed ACL check and then produce an error. > So the ACL tracking needs to be precise: we can't track an ACL check > unless a failure always causes transaction abort; and we must track an > ACL check if it would cause a transaction abort. Right? I would say: we just need to track (and recheck) ACL checks that succeeded. I think that there is no reason to recheck (and so to record) a failed ACL as what we are dealing with here is the TOCTOU window. Re-checking a failed ACL check would handle cases when a GRANT has been given during the TOCTOU window which is not useful (for our protection goal) compared to re-checking a REVOKE during the TOCTOU window (as the latter would record a dependency on an object we don't have permission on). Doing so, as proposed in 0002, allows us to fix the "re-check a harmless failed ACL bug" (demonstrated by the added test) and still protect us for REVOKE during the TOCTOU window. Thoughts? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com