Re: Extension pg_trgm, permissions and pg_dump order
От | Nathan Bossart |
---|---|
Тема | Re: Extension pg_trgm, permissions and pg_dump order |
Дата | |
Msg-id | 20220622162550.GA95419@nathanxps13 обсуждение исходный текст |
Ответ на | Re: Extension pg_trgm, permissions and pg_dump order (Noah Misch <noah@leadboat.com>) |
Список | pgsql-bugs |
On Tue, Jun 21, 2022 at 08:37:04PM -0700, Noah Misch wrote: > On Tue, Jun 21, 2022 at 10:56:16AM -0700, Nathan Bossart wrote: >> On Wed, Jun 15, 2022 at 10:42:18PM -0700, Noah Misch wrote: >> > + * Identify the opclass to use. Use of ddl_userid is necessary due to >> > + * ACL checks therein. This is safe despite opclasses containing >> > + * opaque expressions (specifically, functions), because only >> > + * superusers can define opclasses. >> >> It's not clear to me why the fact that only superusers can define opclasses >> makes this safe. > > classOidP[attn] = ResolveOpClass(attribute->opclass, > atttype, > accessMethodName, > accessMethodId); > > To write the comment, I pondered how those four arguments could conceivably > lead ResolveOpClass() to locate Trojan code. Since only superusers can define > opclasses, we can assume the catalog entries of an opclass do not point to > Trojan code. (The superuser could just do the mischief directly, rather than > going to extra trouble to set a trap for later.) If you see a hole in that > thinking, please do share. Thanks for clarifying. That makes sense to me. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
В списке pgsql-bugs по дате отправления: