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>
 <CAJDiXgihovkP6DMAFyJtYF4JSAjvKmiRVbF5R5n3SA=Yag32_w@mail.gmail.com>
In-Reply-To: 
 <CAJDiXgihovkP6DMAFyJtYF4JSAjvKmiRVbF5R5n3SA=Yag32_w@mail.gmail.com>
From: Soumya S Murali <soumyamurali.work@gmail.com>
Date: Wed, 8 Apr 2026 14:47:28 +0530
Message-ID: 
 <CAMtXxw8pHLH9+mG3wxsF8f=Y+pHqTNP8X1UmZQPkRL9pZ5aF2w@mail.gmail.com>
Subject: Re: Fix bug with accessing to temporary tables of other sessions
To: Daniil Davydov <3danissimo@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jim Jones <jim.jones@uni-muenster.de>,
	Stepan Neretin <slpmcf@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/mixed; boundary="000000000000eab0fa064eef5c38"
Archived-At: 
 <https://www.postgresql.org/message-id/CAMtXxw8pHLH9%2BmG3wxsF8f%3DY%2BpHqTNP8X1UmZQPkRL9pZ5aF2w%40mail.gmail.com>
Precedence: bulk

--000000000000eab0fa064eef5c38
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,

On Wed, Mar 25, 2026 at 12:38=E2=80=AFPM Daniil Davydov <3danissimo@gmail.c=
om> wrote:
>
> Hi,
>
> On Wed, Mar 25, 2026 at 1:58=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrot=
e:
> >
> > > 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.
> >
>
> I've never dealt with the ACL system before, so it's hard for me to asses=
s
> 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 dealin=
g
> > >> with other sessions' temp tables, and we need to un-break the buffer
> > >> manager's defense for that implementation restriction.  So I feel th=
e
> > >> 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 seem=
s 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 i=
s
> physically impossible for them to read the pages of such tables. And if s=
ome
> 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 pa=
ges
> access must be forbidden, and the buffer manager layer is an appropriate =
place
> 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, ReadBufferExten=
ded),
> 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. B=
ut
> > > 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 "relpersist=
ence"
> 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 s=
ure
> 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.


I worked on the issue of accessing temporary tables belonging to other
sessions and tried implementing the fix at the buffer manager level,
as suggested. I added checks in ReadBuffer_common() and
PrefetchBuffer() to reject access when a relation is temporary
(relpersistence =3D TEMP) but does not use local buffers
(!RelationUsesLocalBuffers) so that it ensures only heap page access
is blocked, while catalog lookups and other metadata operations
continue to work as before. While testing, I observed that in many
cases the query does not reach the buffer manager because name
resolution fails earlier with =E2=80=9Crelation does not exist=E2=80=9D. Ho=
wever, the
added checks ensure that even if execution reaches the buffer layer,
access to other sessions=E2=80=99 temporary tables is safely rejected. The
change is minimal, and did not modify parser/ACL behavior and all
regression tests got passed successfully too.
Kindly review the attached patch herewith. Please let me know if this
approach aligns with expectations or if further adjustments are
needed.


Regards,
Soumya

--000000000000eab0fa064eef5c38
Content-Type: text/x-patch; charset="US-ASCII";
	name="0001-prevent-access-to-other-sessions-temporary-tables.patch"
Content-Disposition: attachment;
	filename="0001-prevent-access-to-other-sessions-temporary-tables.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mnptz4g70>
X-Attachment-Id: f_mnptz4g70

RnJvbSA4OGVhNjc1MjMzZjMwNzhjNzc3NDBjYTNlZjI0OTNkMTEzODFjM2Q5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBTb3VteWEgPHNvdW15YW11cmFsaS53b3JrQGdtYWlsLmNvbT4K
RGF0ZTogV2VkLCA4IEFwciAyMDI2IDEyOjQ3OjQ1ICswNTMwClN1YmplY3Q6IFtQQVRDSF0gcHJl
dmVudCBhY2Nlc3MgdG8gb3RoZXIgc2Vzc2lvbnMnIHRlbXBvcmFyeSB0YWJsZXMKClNpZ25lZC1v
ZmYtYnk6IFNvdW15YSA8c291bXlhbXVyYWxpLndvcmtAZ21haWwuY29tPgotLS0KIHNyYy9iYWNr
ZW5kL3N0b3JhZ2UvYnVmZmVyL2J1Zm1nci5jIHwgMzIgKysrKysrKysrKysrKysrKysrKysrLS0t
LS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCAyNCBpbnNlcnRpb25zKCspLCA4IGRlbGV0aW9ucygtKQoK
ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL3N0b3JhZ2UvYnVmZmVyL2J1Zm1nci5jIGIvc3JjL2Jh
Y2tlbmQvc3RvcmFnZS9idWZmZXIvYnVmbWdyLmMKaW5kZXggM2NjMGIwYmRkOTIuLmVjNzJmYTk3
ZWE2IDEwMDY0NAotLS0gYS9zcmMvYmFja2VuZC9zdG9yYWdlL2J1ZmZlci9idWZtZ3IuYworKysg
Yi9zcmMvYmFja2VuZC9zdG9yYWdlL2J1ZmZlci9idWZtZ3IuYwpAQCAtNzkxLDExICs3OTEsMTYg
QEAgUHJlZmV0Y2hCdWZmZXIoUmVsYXRpb24gcmVsbiwgRm9ya051bWJlciBmb3JrTnVtLCBCbG9j
a051bWJlciBibG9ja051bSkKIAogCWlmIChSZWxhdGlvblVzZXNMb2NhbEJ1ZmZlcnMocmVsbikp
CiAJewotCQkvKiBzZWUgY29tbWVudHMgaW4gUmVhZEJ1ZmZlckV4dGVuZGVkICovCi0JCWlmIChS
RUxBVElPTl9JU19PVEhFUl9URU1QKHJlbG4pKQotCQkJZXJlcG9ydChFUlJPUiwKLQkJCQkJKGVy
cmNvZGUoRVJSQ09ERV9GRUFUVVJFX05PVF9TVVBQT1JURUQpLAotCQkJCQkgZXJybXNnKCJjYW5u
b3QgYWNjZXNzIHRlbXBvcmFyeSB0YWJsZXMgb2Ygb3RoZXIgc2Vzc2lvbnMiKSkpOworCQkvKiBB
Q0NFU1MgREVOSUVEIENIRUNLICovCisJCWlmIChyZWxuICE9IE5VTEwgJiYKKyAgICAJCXJlbG4t
PnJkX3JlbCAhPSBOVUxMICYmCisgICAgCQlyZWxuLT5yZF9yZWwtPnJlbHBlcnNpc3RlbmNlID09
IFJFTFBFUlNJU1RFTkNFX1RFTVAgJiYKKyAgICAJCSFSZWxhdGlvblVzZXNMb2NhbEJ1ZmZlcnMo
cmVsbikpCisJCXsKKyAgICAJCWVyZXBvcnQoRVJST1IsCisgICAgICAgICAgICAJCShlcnJjb2Rl
KEVSUkNPREVfRkVBVFVSRV9OT1RfU1VQUE9SVEVEKSwKKyAgICAgICAgICAgICAJCWVycm1zZygi
Y2Fubm90IGFjY2VzcyB0ZW1wb3JhcnkgdGFibGVzIG9mIG90aGVyIHNlc3Npb25zIikpKTsKKwkJ
fQogCiAJCS8qIHBhc3MgaXQgb2ZmIHRvIGxvY2FsYnVmLmMgKi8KIAkJcmV0dXJuIFByZWZldGNo
TG9jYWxCdWZmZXIoUmVsYXRpb25HZXRTbWdyKHJlbG4pLCBmb3JrTnVtLCBibG9ja051bSk7CkBA
IC05MzMsNyArOTM4LDggQEAgUmVhZEJ1ZmZlckV4dGVuZGVkKFJlbGF0aW9uIHJlbG4sIEZvcmtO
dW1iZXIgZm9ya051bSwgQmxvY2tOdW1iZXIgYmxvY2tOdW0sCiAJICogbGlrZWx5IHRvIGdldCB3
cm9uZyBkYXRhIHNpbmNlIHdlIGhhdmUgbm8gdmlzaWJpbGl0eSBpbnRvIHRoZSBvd25pbmcKIAkg
KiBzZXNzaW9uJ3MgbG9jYWwgYnVmZmVycy4KIAkgKi8KLQlpZiAoUkVMQVRJT05fSVNfT1RIRVJf
VEVNUChyZWxuKSkKKwlpZiAocmVsbi0+cmRfcmVsLT5yZWxwZXJzaXN0ZW5jZSA9PSBSRUxQRVJT
SVNURU5DRV9URU1QICYmCisgICAgIVJlbGF0aW9uVXNlc0xvY2FsQnVmZmVycyhyZWxuKSkKIAkJ
ZXJlcG9ydChFUlJPUiwKIAkJCQkoZXJyY29kZShFUlJDT0RFX0ZFQVRVUkVfTk9UX1NVUFBPUlRF
RCksCiAJCQkJIGVycm1zZygiY2Fubm90IGFjY2VzcyB0ZW1wb3JhcnkgdGFibGVzIG9mIG90aGVy
IHNlc3Npb25zIikpKTsKQEAgLTEzMTMsOSArMTMxOSwxOSBAQCBSZWFkQnVmZmVyX2NvbW1vbihS
ZWxhdGlvbiByZWwsIFNNZ3JSZWxhdGlvbiBzbWdyLCBjaGFyIHNtZ3JfcGVyc2lzdGVuY2UsCiAJ
fQogCiAJaWYgKHJlbCkKLQkJcGVyc2lzdGVuY2UgPSByZWwtPnJkX3JlbC0+cmVscGVyc2lzdGVu
Y2U7CisgICAgCXBlcnNpc3RlbmNlID0gcmVsLT5yZF9yZWwtPnJlbHBlcnNpc3RlbmNlOwogCWVs
c2UKLQkJcGVyc2lzdGVuY2UgPSBzbWdyX3BlcnNpc3RlbmNlOworICAgIAlwZXJzaXN0ZW5jZSA9
IHNtZ3JfcGVyc2lzdGVuY2U7CisKKwkvKiBBQ0NFU1MgREVOSUVEICovCisJaWYgKHJlbCAhPSBO
VUxMICYmCisgICAgCXBlcnNpc3RlbmNlID09IFJFTFBFUlNJU1RFTkNFX1RFTVAgJiYKKyAgICAh
CVJlbGF0aW9uVXNlc0xvY2FsQnVmZmVycyhyZWwpKQorCXsKKyAgICAJZXJlcG9ydChFUlJPUiwK
KyAgICAgICAgICAgIChlcnJjb2RlKEVSUkNPREVfRkVBVFVSRV9OT1RfU1VQUE9SVEVEKSwKKyAg
ICAgICAgICAgIGVycm1zZygiY2Fubm90IGFjY2VzcyB0ZW1wb3JhcnkgdGFibGVzIG9mIG90aGVy
IHNlc3Npb25zIikpKTsKKwl9CQogCiAJaWYgKHVubGlrZWx5KG1vZGUgPT0gUkJNX1pFUk9fQU5E
X0NMRUFOVVBfTE9DSyB8fAogCQkJCSBtb2RlID09IFJCTV9aRVJPX0FORF9MT0NLKSkKLS0gCjIu
MzQuMQoK
--000000000000eab0fa064eef5c38--