Nathan Bossart writes:
> Perhaps another variation
> on this idea is to create a query walker that just looks for hasRowSecurity
> flags throughout the tree (and to use that to mark the plan cache entry
> appropriately).
That seems like a pretty plausible compromise position. So we'd
redefine Qu
On Mon, Feb 17, 2025 at 01:08:29PM -0500, Tom Lane wrote:
> I think you're being too impatient. It's still an interesting
> topic, it just needs more thought to get to something committable.
Maybe I am. Thanks for chiming in.
> I find this has-row-security marking problem to be comparable
> to
Nathan Bossart writes:
> Given there doesn't seem to be a huge amount of interest in this, I plan to
> mark it as Withdrawn soon.
I think you're being too impatient. It's still an interesting
topic, it just needs more thought to get to something committable.
I find this has-row-security marking
Given there doesn't seem to be a huge amount of interest in this, I plan to
mark it as Withdrawn soon.
--
nathan
IRrules() on more parts of a Query, it's then much more likely
> that the new code won't forget to update the parent query's flag.
I've attempted this in the attached v2 patch. I do think this is an
improvement over the status quo, but I worry that it doesn't go far
On Thu, 21 Nov 2024 at 18:00, Nathan Bossart wrote:
>
> In light of CVE-2024-10976, which was fixed by commit cd7ab57, I'd like to
> propose a bigger change to this area of the code that aims to future-proof
> it a bit. Instead of requiring hackers to carefully cart around whether a
> query refer
ing code, especially the stuff added by commit cd7ab57.
Thoughts?
--
nathan
>From 7645f3a7215b052ab29be6d8e2b6e84954cb5caf Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 21 Nov 2024 11:57:43 -0600
Subject: [PATCH v1 1/1] revamp row-security tracking
---
src/backend/access/trans
