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>
 <CAJDiXgh9g4TEyF3kWCiBgHX6QbpATZtxTfrQuBCKxUO5=nZBOw@mail.gmail.com>
 <4075754.1774378690@sss.pgh.pa.us>
In-Reply-To: <4075754.1774378690@sss.pgh.pa.us>
From: Daniil Davydov <3danissimo@gmail.com>
Date: Wed, 25 Mar 2026 14:07:52 +0700
Message-ID: 
 <CAJDiXgihovkP6DMAFyJtYF4JSAjvKmiRVbF5R5n3SA=Yag32_w@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/CAJDiXgihovkP6DMAFyJtYF4JSAjvKmiRVbF5R5n3SA%3DYag32_w%40mail.gmail.com>
Precedence: bulk

Hi,

On Wed, Mar 25, 2026 at 1:58=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > Actually, v12 patch is not about a superuser rights restriction, but ab=
out
> > forbidding such operations for everyone.
>
> ... including superusers, who bypass permissions restrictions
> everywhere else.  You are going to have to contort the ACL system
> badly to make that happen at all, and I would not be surprised
> if you introduce new bugs.
>

I've never dealt with the ACL system before, so it's hard for me to assess
the scale of the problem. I am inclined to believe you on this issue.

> >> 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.pg=
h.pa.us
>
> > Handling access to other-temp-tables on the buffer manager level seems =
to me
> > like fighting the symptom, not the cause.
>
> No, it IS the cause.  If someday someone were to reimplement buffer
> management in a way that didn't have this implementation restriction,
> we would surely not arbitrarily restrict superusers from looking at
> tables that they then would physically be able to look at.
>

OK, now I fully understand your point (I hope so) :
We want to restrict backend access to other-temp-tables just because it is
physically impossible for them to read the pages of such tables. And if som=
e
users has enough privileges, it is OK for us to allow them to
lock/vacuum/drop/... other-temp-tables. I.e. only operations with heap page=
s
access must be forbidden, and the buffer manager layer is an appropriate pl=
ace
for it.

> > Am I missing something?
>
> Mainly, that we had a setup that was working fine for decades,
> until somebody made holes in it with careless refactoring.
> We should fix that mistake, not introduce inconsistent-with-
> decades-of-practice permissions behavior to hide the mistake
> at an unrelated logical level.
>

Yeah, we have a few checks in the bufmgr (PrefetchBuffer, ReadBufferExtende=
d),
but they stopped coping with their task.

> Also, we need a defense at the buffer manager level anyway, because
> otherwise C code could try to access another session's temp table
> and we'd not realize it was getting bogus answers.  (Whether such
> an attempt is a bug or not is a different discussion; but we at
> least need some logic that detects that it won't work, and the ACL
> system cannot be expected to stop C-level code from trying.)
>
> Also, we really need a patch that's simple and non-invasive enough
> to be back-patched into v17 and v18.  This proposal is not that.
>

OK

>
> > 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.
>
> I do kind of agree with this concern, but the v12 patch simply moves
> the untruthfulness around.  Reality is that we cannot know whether an
> unqualified-name RangeVar references a temp table until we do a
> catalog lookup, ...

Yep, Jim's example shows us that we cannot always rely on the "relpersisten=
ce"
field.

> ...so IMO we should not have a relpersistence field there
> at all.  At best it means something quite different from what it means
> elsewhere, and that's a recipe for confusion.  But changing that would
> not be a bug fix (AFAIK) but refactoring to reduce the probability of
> future bugs.
>

I agree with the idea to get rid of this field. By now I cannot say for sur=
e
whether we can fix a bug without modifying the RangeVar structure. But I'll
try to implement proposed logic only within the bufmgr.


Thank you very much for your comments! I'll post a new patch in the near
future.

--
Best regards,
Daniil Davydov