Re: Revoke Connect Privilege from Database not working
| От | Nathan Bossart |
|---|---|
| Тема | Re: Revoke Connect Privilege from Database not working |
| Дата | |
| Msg-id | aatOzgie9RlzbGoo@nathan обсуждение исходный текст |
| Ответ на | Re: Revoke Connect Privilege from Database not working (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-bugs |
On Wed, Jan 21, 2026 at 11:57:01AM -0500, Tom Lane wrote: > Nathan Bossart <nathandbossart@gmail.com> writes: >> Yeah, I think doing most of the work in select_best_grantor() is obviously >> better. I recall wondering whether we should check for INHERIT or SET >> privilege (or both) on the grantor role, and IIRC I settled on INHERIT >> because select_best_grantor() searches through roles we have INHERIT on. > > Yeah, I mentally had that point as something to check on. Clearly, > if you have SET ROLE privilege then you can become the target role > and then issue the GRANT, so if we define GRANTED BY like that > then we're not allowing anything that can't be done today. However, > it feels like INHERIT is a more natural test to make, since AIUI > that is what permits "automatic" use of a role's privileges, and that > seems to be what we'd be doing here. Agreed. > I'd be interested to hear Robert's opinion on this, or somebody > else who worked on the SET/INHERIT splitup. > > Also cc'ing Peter, who put in the current effectively-a-noise-clause > behavior of GRANTED BY, to see if he has standards-compliance or > other concerns about changing this. Robert/Peter, do you have any thoughts about expanding GRANT/REVOKE GRANTED BY like this? I think it would've helped with a couple of reports received during this development cycle, and IMHO it'd be a nice little feature for v19. -- nathan
В списке pgsql-bugs по дате отправления: