Re: Why ACL_EXECUTE is checked on FindConversion()?
От | KaiGai Kohei |
---|---|
Тема | Re: Why ACL_EXECUTE is checked on FindConversion()? |
Дата | |
Msg-id | 4A8C8FBD.8010000@ak.jp.nec.com обсуждение исходный текст |
Ответ на | Re: Why ACL_EXECUTE is checked on FindConversion()? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
[PATCH] Remove obscure permission checks in FindConversion()
|
Список | pgsql-hackers |
Tom Lane wrote: > KaiGai Kohei <kaigai@ak.jp.nec.com> writes: >> When FindConversion() is called, it also checks current user's ACL_EXECUTE >> privilege on the conproc of the fetched conversion. > >> Why this check is applied on FindConversion(), instead of FindDefaultConversion()? > > Does seem pretty inconsistent, doesn't it? Anyway, I could not understand the intention of the checks, rather than inconsistency. So, I doubted it might be a bug, if it intended to provide a permission something like ACL_USAGE on conversion. > The original idea may have been to provide a substitute for a USAGE > ACL check on conversions, in which case it's not totally insane: if > you make a conversion default then you're implicitly granting it to > public. But there's no documentation about this. If ACL_EXECUTE checks is deployed on FindDefaultConversion(), it performs as if something like ACL_USAGE permission. However, FindConversion() is called from ALTER or DROP CONVERSION, so it controls DDL statements in addition to its ownership. Please note that this check (ACL_EXECUTE) is not applied when user choose a certain conversion. > Offhand I see no really good reason to have a usage check on > conversions, and would be happy with removing this one. The function > permission check at CREATE CONVERSION time ought to be sufficient. It seems to me reasonable. If user does not have ACL_EXECUTE privilege on the function used in the conversion, he does not alter or drop the conversion, even if he has ownership of the conversion. This behavior is hard to understand. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления: