Isaac Morland writes:
> On Mon, 2 Jun 2025 at 22:52, jian he wrote:
> Do we consider INSERT associated with user defined function a security
>> bug?
> A very old issue for INSERT/UPDATE/DELETE, but until this patch not an
> issue for SELECT from a table (although if I understand correctly earlie
On Mon, 2 Jun 2025 at 22:52, jian he wrote:
Do we consider INSERT associated with user defined function a security
> bug? for
> example, the following, INSERT with a check constraint.
>
[]
If so, then it's a very old issue...
>
A very old issue for INSERT/UPDATE/DELETE, but until this pat
On Tue, Jun 3, 2025 at 9:19 AM Tom Lane wrote:
>
> In any case, this doesn't feel like something to be defining and
> implementing post-beta1. Even if it were not security-critical,
> the amount of complication involved is well past our standards
> for what can go in post-feature-freeze.
>
> I'm
On Mon, 2025-06-02 at 21:19 -0400, Tom Lane wrote:
> Maybe we can make a conservative approximation that's good
> enough to be useful, but I'm not certain.
Right. If the alternative is reverting the feature, the idea would be
to save it for at least some common use cases where the expression is
ob
Jeff Davis writes:
> On Thu, 2025-05-29 at 11:12 -0400, Tom Lane wrote:
>> Perhaps a compromise is to invent RunAsUser but only apply it to
>> virtual columns for now, leaving the view case as a research
>> project. Then we aren't destroying the performance of any
>> existing queries.
> Could we
On Thu, 2025-05-29 at 11:12 -0400, Tom Lane wrote:
> Perhaps a compromise is to invent RunAsUser but only apply it to
> virtual columns for now, leaving the view case as a research
> project. Then we aren't destroying the performance of any
> existing queries.
Could we instead check that the expr
On Thu, May 29, 2025 at 02:15:22PM -0400, Tom Lane wrote:
> Feike Steenbergen writes:
> > pg_restore may have issues though, as it will run these functions
> > for GENERATED STORED columns?
>
> pg_restore is already fairly exposed, as it will run tables' CHECK
> constraints, index expressions, et
On Thu, 29 May 2025 at 20:30, Tom Lane wrote:
>
> Matthias van de Meent writes:
> > On Thu, 29 May 2025 at 15:44, Robert Haas wrote:
> >> But so far - apart from this feature - we
> >> have managed to avoid making it categorically unsafe for the superuser
> >> to run "SELECT * FROM table"
>
> >
On Thu, 29 May 2025 at 15:44, Robert Haas wrote:
> But so far - apart from this feature - we
> have managed to avoid making it categorically unsafe for the superuser
> to run "SELECT * FROM table"
With CREATE RULE [0], a table owner can redefine what happens during
e.g. SELECT * FROM table. This
Matthias van de Meent writes:
> On Thu, 29 May 2025 at 15:44, Robert Haas wrote:
>> But so far - apart from this feature - we
>> have managed to avoid making it categorically unsafe for the superuser
>> to run "SELECT * FROM table"
> With CREATE RULE [0], a table owner can redefine what happens
Feike Steenbergen writes:
> pg_restore may have issues though, as it will run these functions
> for GENERATED STORED columns?
pg_restore is already fairly exposed, as it will run tables' CHECK
constraints, index expressions, etc. I don't think GENERATED STORED
makes that picture much worse.
As
On Thu, 29 May 2025 at 15:43, Robert Haas wrote:
> that would also imply,
> for example, that there's no way to run a pg_dump without letting any
> user on the system obtain superuser privileges.
I checked, pg_dump seems safe, it doesn't extract the values, even when
using --column-inserts.
pg_r
"David G. Johnston" writes:
> Just to make sure we are on the same page as to who IS supposed to be
> "current_user" within these functions - it should be the table owner, right?
If we could make that happen (ie, run the generated-column expressions
as the table owner), it would likely be a suffi
On Thu, May 29, 2025 at 6:43 AM Robert Haas wrote:
>
> Point being: this
> feature will need to be fixed in some way that avoids further
> expanding the set of things that a superuser must not ever do for fear
> of giving away their privileges accidentally, or else it will need to
> be reverted.
On Mon, May 26, 2025 at 10:52 AM Feike Steenbergen
wrote:
> On Mon, 26 May 2025 at 16:17, jian he wrote:
> > calling exploit_generated.exploit by normal user or superuser the
> > effects are different,
> > that by definition is not IMMUTABLE.
>
> Yeah, i know this is *wrong* usage of IMMUTABLE, t
On Mon, 26 May 2025 at 16:17, jian he wrote:
> calling exploit_generated.exploit by normal user or superuser the
> effects are different,
> that by definition is not IMMUTABLE.
Yeah, i know this is *wrong* usage of IMMUTABLE, the point is that a rogue
regular user *can* use this pattern to become
On Mon, May 26, 2025 at 4:56 PM Feike Steenbergen
wrote:
>
>
>
> On Sat, 24 May 2025 at 15:43, jian he wrote:
> > sorry, I am not fully sure what this means. a minimum sql reproducer would
> > be
> > great.
>
> The initial email contains a fully self-contained example of a regular user
> becomin
On Sat, 24 May 2025 at 15:43, jian he wrote:
> sorry, I am not fully sure what this means. a minimum sql reproducer
would be
> great.
The initial email contains a fully self-contained example of a regular user
becoming a superuser. The only thing the superuser had to do was
SELECT * FROM unt
On Saturday, May 24, 2025, jian he wrote:
> On Sat, May 24, 2025 at 2:39 PM Feike Steenbergen
> wrote:
> >
> > The loophole is this:
> >
> > - the generated virtual column can use a user-defined function
> > - when running SELECT against that column by a superuser
> > the function is called wi
On Sat, May 24, 2025 at 2:39 PM Feike Steenbergen
wrote:
>
> The loophole is this:
>
> - the generated virtual column can use a user-defined function
> - when running SELECT against that column by a superuser
> the function is called within the context of a superuser
> - this in turn allows the
On Fri, 23 May 2025 at 14:48, jian he wrote:
> when you mark it as IMMUTABLE, postgres think it's IMMUTABLE, but in this
case
> exploit_generated.exploit(i int) clearly is not an IMMUTABLE function.
>
> Only IMMUTABLE functions are allowed in generated expressions,
> but you can still misuse it by
On Fri, May 23, 2025 at 4:43 PM Feike Steenbergen
wrote:
>
>
> Hi,
>
> While evaluating the PostgreSQL 18 beta, I had a thought experiment where I
> thought it might be possible to use the new virtual generated columns to gain
> superuser privileges for a regular user.
>
> Attached is a sample exp
Hi,
While evaluating the PostgreSQL 18 beta, I had a thought experiment where I
thought it might be possible to use the new virtual generated columns to
gain
superuser privileges for a regular user.
Attached is a sample exploit, that achieves this, key components:
- the GENERATED column uses a u
23 matches
Mail list logo
