Обсуждение: [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
Вложения
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.