Thread: [HACKERS] 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
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
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.
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
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.