On 23.06.25 15:13, Peter Eisentraut wrote:
Your CheckAttributeType() change is conditional on TYPTYPE_BASE, but if
you remove that and check it for all types, then you get the right error
in both cases.
I have attached a patch that is similar to yours but with that change.
I've also written t
On 23.06.25 18:11, jian he wrote:
seems we didn't check the ALTER TABLE case.
CREATE TYPE double_int as (a int, b int);
CREATE TABLE y (a int);
alter table y add column b double_int GENERATED ALWAYS AS ((a * 2, a *
3)) VIRTUAL;
in ATExecAddColumn, we can change it to:
CheckAttributeType(Na
On Mon, Jun 23, 2025 at 9:13 PM Peter Eisentraut wrote:
>
> >
> > Note: Support for composite types in virtual generated columns is
> > currently partial.
> > for example:
> >
> > CREATE TYPE double_int as (a int, b int);
> > --ok
> > CREATE TABLE gtest4 (
> > a int,
> > b double_int GEN
On 21.06.25 16:45, jian he wrote:
CREATE TABLE gtest1 (a int42 GENERATED ALWAYS AS ('1') VIRTUAL);
CREATE TABLE gtest2 (a int42 GENERATED ALWAYS AS ('1'::int42) VIRTUAL);
ERROR: generation expression uses user-defined type
LINE 1: CREATE TABLE gtest2 (a int42 GENERATED ALWAYS AS ('1'::int42...
On Sat, Jun 21, 2025 at 1:29 PM jian he wrote:
>
> ( the following excerpted from create_type.sql)
>
> BEGIN;
> CREATE TYPE int42;
> -- Make dummy I/O routines using the existing internal support for int4, text
> CREATE FUNCTION int42_in(cstring)
>RETURNS int42
>AS 'int4in'
>LANGUAGE i
On Thu, Jun 19, 2025 at 5:11 AM Peter Eisentraut wrote:
> Here is a new patch.
>
> My previous patch was a bit too simple. I had thought that
> check_functions_in_node() does the node walking itself, but that was
> wrong, so the patch only worked at the top-level of the expression. So
> I had to
On 05.06.25 12:49, Peter Eisentraut wrote:
On 23.05.25 10:43, Feike Steenbergen wrote:
Attached is a sample exploit, that achieves this, key components:
- the GENERATED column uses a user defined immutable function
- this immutable function cannot ALTER ROLE (needs volatile)
- therefore this im
On Thu, Jun 5, 2025 at 7:24 PM Feike Steenbergen
wrote:
>
> On Thu, 5 Jun 2025 at 12:49, Peter Eisentraut wrote:
> > I propose to address this by not allowing the use of user-defined
> > functions in generation expressions for now. The attached patch
> > implements this. This assumes that all b
On Thu, Jun 5, 2025 at 11:19 AM jian he wrote:
> I think it will work.
> because we already require the generated column expression to be
> immutable functions.
>
> The above functions you mentioned are all not immutable.
Hmm. I guess I have no evidence that we have built-in immutable
functions t
Re: Tom Lane
> > Extending the idea, perhaps the check could be moved to run-time and
> > recursively check that only immutable functions are called, including
> > user-defined immutable functions?
>
> I don't think I'd trust that. UDFs can claim to be immutable but
> be lying about it.
That's w
Christoph Berg writes:
> So the question is, are all built-in *immutable* functions safe?
Perhaps.
> Extending the idea, perhaps the check could be moved to run-time and
> recursively check that only immutable functions are called, including
> user-defined immutable functions?
I don't think I'd
Re: Robert Haas
> I don't think this is sufficient to fix the problem. We have built-in
> functions that are unsafe. These include LO functions like loread(),
> lowrite(), lo_unlink(); functions that change session state like
> set_config() and setseed(); functions that allow arbitrary query
> exec
On Thu, Jun 5, 2025 at 10:39 PM Robert Haas wrote:
>
> On Thu, Jun 5, 2025 at 6:49 AM Peter Eisentraut wrote:
> > I propose to address this by not allowing the use of user-defined
> > functions in generation expressions for now. The attached patch
> > implements this. This assumes that all buil
On Thu, Jun 5, 2025 at 6:49 AM Peter Eisentraut wrote:
> I propose to address this by not allowing the use of user-defined
> functions in generation expressions for now. The attached patch
> implements this. This assumes that all built-in functions are
> trustworthy, for this purpose, which seem
On Thu, 5 Jun 2025 at 12:49, Peter Eisentraut wrote:
> I propose to address this by not allowing the use of user-defined
> functions in generation expressions for now. The attached patch
> implements this. This assumes that all built-in functions are
> trustworthy, for this purpose, which seems
čt 5. 6. 2025 v 12:49 odesílatel Peter Eisentraut
napsal:
> On 23.05.25 10:43, Feike Steenbergen wrote:
> > Attached is a sample exploit, that achieves this, key components:
> >
> > - the GENERATED column uses a user defined immutable function
> > - this immutable function cannot ALTER ROLE (need
On 23.05.25 10:43, Feike Steenbergen wrote:
Attached is a sample exploit, that achieves this, key components:
- the GENERATED column uses a user defined immutable function
- this immutable function cannot ALTER ROLE (needs volatile)
- therefore this immutable function calls a volatile function
-
On Tue, 2025-06-03 at 11:27 -0400, Robert Haas wrote:
> That's true, but search_path manipulation is still enough to cause
> quite a few problems.
+1. The only defense is to declare the function with "SET search_path",
but until recently, that was a major performance penalty for cheap
functions. A
On Tue, Jun 3, 2025 at 10:11 AM Bruce Momjian wrote:
> I think the two cases are slightly different. Our existing system has
> users running triggers on tables that don't own as themselves, so the
> table owner has full control over what is in the triggers. If we were
> to switch it so users run
On Tue, Jun 3, 2025 at 08:58:58AM -0400, Robert Haas wrote:
> On Mon, Jun 2, 2025 at 11:30 PM Tom Lane wrote:
> > > That being said I would like to see it corrected everywhere.
> >
> > Yeah, one approach we could take here is to try to move the goalposts
> > for this whole topic, understanding th
On Mon, 2 Jun 2025 at 23:30, Tom Lane wrote:
> Isaac Morland writes:
>
> My fix would
> > be for check constraints, triggers, and view definitions to run as the
> > owner of the object in question (constraint, trigger, or view or
> > materialized view), essentially using the same facility as us
On Mon, Jun 2, 2025 at 11:30 PM Tom Lane wrote:
> > That being said I would like to see it corrected everywhere.
>
> Yeah, one approach we could take here is to try to move the goalposts
> for this whole topic, understanding that that will mean incompatible
> changes as well as some performance lo
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
45 matches
Mail list logo
