Re: Clarification on Role Access Rights to Table Indexes
От | Jeff Davis |
---|---|
Тема | Re: Clarification on Role Access Rights to Table Indexes |
Дата | |
Msg-id | 857a4633aea6ef90bde4156ae351c49794b34732.camel@j-davis.com обсуждение исходный текст |
Ответ на | Re: Clarification on Role Access Rights to Table Indexes (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: Clarification on Role Access Rights to Table Indexes
|
Список | pgsql-hackers |
On Tue, 2025-10-14 at 11:05 -0500, Nathan Bossart wrote: > For > pg_prewarm, I don't know. You do have to install the extension > before > using it, but once installed, it's available to everyone by default. > My > guess is that it just hasn't been a problem in the field. If we start with an OID, what's the right way to do these kinds of checks? Could we do an ACL check, then lock it, then do an ACL check again to catch OID wraparound? Last-minute suggestions on 0003: * Add a comment around the privOid check to explain that, if the object is an index, we must check the privileges on the table instead. * Clarify in the comment that the race against index drop/recreation involves OID wraparound. +1 to the patch and backpatch. As a separate thought, I'm wondering if we should do more to enforce the idea that we check the privileges and owner of an index's table, and never the index itself. That's for another discussion, though. > Regardless, fixing the lock-before-privilege-checks behavior doesn't > strike > me as a bug, so I think we ought to proceed with something like 0003 > for > back-patching purposes and then to rework it further for v19. Does > that > sound okay to you? According to the current rules[1], it does seem to technically be a bug, but as far as I can tell, not one of much consequence. Regards, Jeff Davis [1] https://www.postgresql.org/message-id/976405.1760459426@sss.pgh.pa.us
В списке pgsql-hackers по дате отправления: