Re: Clarification on Role Access Rights to Table Indexes
От | Nathan Bossart |
---|---|
Тема | Re: Clarification on Role Access Rights to Table Indexes |
Дата | |
Msg-id | aO50zOmoRFnB9_IX@nathan обсуждение исходный текст |
Ответ на | Re: Clarification on Role Access Rights to Table Indexes (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Clarification on Role Access Rights to Table Indexes
|
Список | pgsql-hackers |
Thanks for reviewing. On Mon, Oct 13, 2025 at 07:23:36PM -0700, Jeff Davis wrote: > The unlikely scenarios are a bit confusing. I'd probably error for > either case. Also, the error message on the second scenario is wrong if > the previous lookup was a table, I think. Yeah, I think that's a better idea. > IIUC this is locking before the privilege check. Is there a reason why > we think this is OK here (and in amcheck_lock_relation_and_check()) but > not for the stats? For amcheck, AFAICT there aren't actually any ACL checks within the code because the function is restricted to superuser by default. 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. 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? >> * 0004 is a small patch to teach dblink to use >> RangeVarGetRelidExtended(). I believe this code predates that >> function. I don't intend to back-patch this one. > > Looks good. I'm going to go commit this one now to get it out of the way. -- nathan
В списке pgsql-hackers по дате отправления: