Ignore tablespace ACLs when ignoring schema ACLs
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t35973psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 08:27 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t35973_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t35973_1 && git checkout t35973_1Patchset v1 (message #1) is on t35973_1
DefineIndex() has a check_rights argument that determines whether to perform a
namespace ACL check. When ALTER TABLE ALTER TYPE rebuilds an index, it sets
that flag. The theory goes that use of DROP INDEX and CREATE INDEX is a mere
implementation detail of ALTER TABLE ALTER TYPE; the operation is logically like
an alteration of the existing index. I think the same treatment should extend
to the tablespace ACL check, as attached.
Noah Misch <noah@leadboat.com> writes:
DefineIndex() has a check_rights argument that determines whether to perform a
namespace ACL check. When ALTER TABLE ALTER TYPE rebuilds an index, it sets
that flag. The theory goes that use of DROP INDEX and CREATE INDEX is a mere
implementation detail of ALTER TABLE ALTER TYPE; the operation is logically like
an alteration of the existing index. I think the same treatment should extend
to the tablespace ACL check, as attached.
Seems generally reasonable.
Is there any likely use-case for providing separate control flags for the
two permission checks? That would require an API change for DefineIndex,
making this considerably more invasive, so I'm not pushing for it ---
just think it's worth asking the question before proceeding.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Feb 05, 2017 at 12:46:41PM -0500, Tom Lane wrote:
Noah Misch <noah@leadboat.com> writes:
DefineIndex() has a check_rights argument that determines whether to perform a
namespace ACL check. When ALTER TABLE ALTER TYPE rebuilds an index, it sets
that flag. The theory goes that use of DROP INDEX and CREATE INDEX is a mere
implementation detail of ALTER TABLE ALTER TYPE; the operation is logically like
an alteration of the existing index. I think the same treatment should extend
to the tablespace ACL check, as attached.Seems generally reasonable.
Is there any likely use-case for providing separate control flags for the
two permission checks? That would require an API change for DefineIndex,
making this considerably more invasive, so I'm not pushing for it ---
just think it's worth asking the question before proceeding.
Good question. I can't think of one.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
On Sun, Feb 05, 2017 at 12:46:41PM -0500, Tom Lane wrote:
Is there any likely use-case for providing separate control flags for the
two permission checks? That would require an API change for DefineIndex,
making this considerably more invasive, so I'm not pushing for it ---
just think it's worth asking the question before proceeding.
Good question. I can't think of one.
Yeah, after some reflection I agree. Basically what we want for the ALTER
TABLE scenario is "ignore *all* permissions checks"; if somebody adds some
other check here in future, it probably also ought to be skipped during
a rebuild. So a single bool ought to be fine.
Are you intending to back-patch this? It seems like a bug fix --- but not
a very high-priority one, so at this point maybe it should wait till after
the release wraps.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Feb 05, 2017 at 01:48:09PM -0500, Tom Lane wrote:
Noah Misch <noah@leadboat.com> writes:
On Sun, Feb 05, 2017 at 12:46:41PM -0500, Tom Lane wrote:
Is there any likely use-case for providing separate control flags for the
two permission checks? That would require an API change for DefineIndex,
making this considerably more invasive, so I'm not pushing for it ---
just think it's worth asking the question before proceeding.Good question. I can't think of one.
Yeah, after some reflection I agree. Basically what we want for the ALTER
TABLE scenario is "ignore *all* permissions checks"; if somebody adds some
other check here in future, it probably also ought to be skipped during
a rebuild. So a single bool ought to be fine.
Right.
Are you intending to back-patch this? It seems like a bug fix --- but not
a very high-priority one, so at this point maybe it should wait till after
the release wraps.
Back-patch after wrap sounds good.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers