Ignore tablespace ACLs when ignoring schema ACLs
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.
Attachments:
tablespace-acl-skip-v1.patchtext/plain; charset=us-asciiDownload+20-5
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