MIME-Version: 1.0
References: 
 <CAJDiXghdFcZ8=nh4G69te7iRr3Q0uFyXxb3ZdG09_GTNZXwH0g@mail.gmail.com>
 <CA+Yyo5TQF51D7vmuksLwrKFqkcg2hmVw_pNaZwEAwpix+qnr9Q@mail.gmail.com>
 <CAJDiXghNBp=MEUdE3pxSLtULoHmkt4WyA4ZEReoE+ihAfX1uxQ@mail.gmail.com>
 <fd8243d0-a217-42d2-8f5c-b1cd5e99f93a@uni-muenster.de>
 <CAJDiXgiA77LhQ8Omnfb3iR+6UfB+h5BjMMxFG1QbewiFSSJF6w@mail.gmail.com>
 <2f3fa419-9000-4e2a-b070-6e35d5de0e4c@uni-muenster.de>
 <CAJDiXgghbz2TL1b5HbvB7pQzM6S4QDxcuLP-tyOzj1tZunvXJA@mail.gmail.com>
 <751a6cb8-cac8-46c4-8c64-9e23f663e926@uni-muenster.de>
 <CAJDiXgiMg_f0A1aESQrwFzeAkUieXBy8vFq_zisvTKQcGQJcCg@mail.gmail.com>
 <CAJDiXgj5rFYxuLYSpQxidQ+1cZ=6rJx29MvV+RAjKX7B=EGUvw@mail.gmail.com>
 <CAJDiXggOEN06RwBBCJ-egzkmTbm81=LJ5eCNmvzr=Bpwnp5VzA@mail.gmail.com>
 <CAJDiXgi7tWm_y0i7kD8fMxGe=86_W-hMxyQS+g7-7cdTzd-KRQ@mail.gmail.com>
 <CAMtXxw_ta_9i=uPJMvGueOBc04crmraJXcyJhN0K=Wu9aa2rog@mail.gmail.com>
 <1a32fc83-df78-4774-97dc-2bb06dbb16e9@uni-muenster.de>
 <3529398.1774273446@sss.pgh.pa.us>
In-Reply-To: <3529398.1774273446@sss.pgh.pa.us>
From: Daniil Davydov <3danissimo@gmail.com>
Date: Wed, 25 Mar 2026 00:26:13 +0700
Message-ID: 
 <CAJDiXgh9g4TEyF3kWCiBgHX6QbpATZtxTfrQuBCKxUO5=nZBOw@mail.gmail.com>
Subject: Re: Fix bug with accessing to temporary tables of other sessions
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jim Jones <jim.jones@uni-muenster.de>,
	Soumya S Murali <soumyamurali.work@gmail.com>,
 Stepan Neretin <slpmcf@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAJDiXgh9g4TEyF3kWCiBgHX6QbpATZtxTfrQuBCKxUO5%3DnZBOw%40mail.gmail.com>
Precedence: bulk

Hi,

On Mon, Mar 23, 2026 at 8:31=E2=80=AFPM Jim Jones <jim.jones@uni-muenster.d=
e> wrote:
>
> This is a step forward in really isolating contents of temp tables from
> other sessions, but the more I think about it, the more I'm concerned
> with the current approach -- I spent some time investigating this
> problem a bit deeper last week.
>
> My main concern is the usage of gram.y, as a parser is arguably fragile
> for this kind of things.

I don't actually want to use gram.y as a main solver of this issue. But
gram.y is setting the "relpersistence" field for the RangeVar and all
subsequent code is treating this value as truthful. In particular, v12 patc=
h
is relying on this field in RangeVar during the resolution of access issues=
,
and IMHO it's not out of line with the current code base. For instance, we =
are
considering RangeVar to determine whether we can perform a CREATE operation
within the specified namespace (see RangeVarAdjustRelationPersistence).

Even if we decide not to touch the gram.y in this patch, I still think that
leaving the "relpesistence" field misleading may lead to more bugs appearin=
g
in the future. I.e. it should be fixed anyway (maybe in another thread?).

> For instance, one can always change the
> search_path and bypass this restriction:
>
> (table t was created in a different session)
>
> postgres=3D# SELECT * FROM pg_temp_81.t;
> ERROR:  cannot access temporary relations of other sessions
> LINE 1: SELECT * FROM pg_temp_81.t;
>                       ^
> postgres=3D# SET search_path =3D pg_temp_81, public;
> SET
> postgres=3D# SELECT * FROM t;
>  ?column?
> ----------
> (0 rows)
>
> * See: if (relation->relpersistence =3D=3D RELPERSISTENCE_TEMP) in
> namespace.c for more details.

Yeah, you are right. It turns out that the current patch doesn't fully
protect other temp tables from superuser. The first thought that comes to m=
e
is to forbid setting other-temp-namespaces in a search_path parameter. I kn=
ow
it's starting to look ugly. But actually, such a restriction seems quite
logical.

>
> IMO, since it is an access control issue, I guess we better treat it as
> such and modify aclchk.c instead.
>
> Something like this the file attached. This breaks an unrelated test,
> which is potentially a bug in REPACK ... but I'll describe it in another
> thread.
>
> Thoughts?

Thank you for the patch! It seems much more beautiful and convenient to
maintain, but I have a little concern about it.

Actually, in your implementation we can DROP other temp tables not because =
we
make an exception to the general rule ("don't touch other temp tables"), bu=
t
because we just can perform such operations with every object in pg_temp_0.
If other operations with the same access checking as DROP command appear in
the future, the user will be able to perform these operations for
other-temp-tables. I.e. we will need to manually prevent such new operation=
s
from accessing other-temp-tables. Have I gone too far in my reasoning?

BTW, your implementation allows calling a VACUUM for other-temp-tables. I t=
hink
that we should forbid that too.

On Mon, Mar 23, 2026 at 8:44=E2=80=AFPM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Jim Jones <jim.jones@uni-muenster.de> writes:
> > This is a step forward in really isolating contents of temp tables from
> > other sessions, but the more I think about it, the more I'm concerned
> > with the current approach -- I spent some time investigating this
> > problem a bit deeper last week.
>
> Yeah.  I think this entire approach is wrongheaded: we do not enforce
> permissions checks against superusers.  Moreover, if we try to fix it
> at the permissions level, it seems nearly certain that there will be
> bypass paths, simply because superusers bypass so many other checks.
>

Actually, v12 patch is not about a superuser rights restriction, but about
forbidding such operations for everyone. Anyway, we have a new perl test th=
at
will prevent adding a code that will allow superuser to (somehow) break the
protection of both mine and Jim's patches. Isn't that a sufficient guarante=
e
that superuser will not bypass checks that it must not bypass?

> The actual problem is that the buffer manager is incapable of dealing
> with other sessions' temp tables, and we need to un-break the buffer
> manager's defense for that implementation restriction.  So I feel the
> correct approach is something similar to what I described here:
>
> https://www.postgresql.org/message-id/flat/2736425.1758475979%40sss.pgh.p=
a.us
>
> I'm not wedded to that specific patch, but that is the implementation
> level where the fix is needed.
>

Handling access to other-temp-tables on the buffer manager level seems to m=
e
like fighting the symptom, not the cause. Protection of other-temp-tables i=
s
kinda "upper-level logical restriction". At the same time, buffer manager i=
s a
lower-level implementation which shouldn't face such upper-level issues.
Am I missing something?

--
Best regards,
Daniil Davydov