Re: Fix bug with accessing to temporary tables of other sessions - Mailing list pgsql-hackers

Daniil Davydov <3danissimo@gmail.com> writes:
> On Mon, Mar 23, 2026 at 8:44 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

... 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.

>> 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.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.

> 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.

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.


> 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, 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.

            regards, tom lane