Re: [HACKERS] GRANT EXECUTE ON FUNCTION foo() TO bar();
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] GRANT EXECUTE ON FUNCTION foo() TO bar(); |
Дата | |
Msg-id | 20187.1487769519@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [HACKERS] GRANT EXECUTE ON FUNCTION foo() TO bar(); (Joel Jacobson <joel@trustly.com>) |
Ответы |
Re: [HACKERS] GRANT EXECUTE ON FUNCTION foo() TO bar();
|
Список | pgsql-hackers |
Joel Jacobson <joel@trustly.com> writes: > Currently, it's only possible to grant/revoke execute on functions to roles. > I think it would be useful in many situations, both for documentation purposes, > but also for increased security, to in a precise way control what > other function(s) are allowed to execute a specific function. I think this is really *not* a good idea. The entire permissions model is built around granting permissions to roles, by other roles. Allowing non-role objects to hold permissions would be a complicated mess and probably create security bugs. Confusing function OIDs with role OIDs is a likely example. Another problem is that roles are installation-wide while functions are not, and all the ACL catalog infrastructure is designed for the permissions-holding entities to be installation-wide. No doubt that could be dealt with, but it would be more complexity and another fertile source of bugs. Complexity in security-related concepts is not a good thing. It's not that hard, if you have needs like this, to make an owning role for each such function. You might end up with a lot of single-purpose roles, but they could be grouped under one or a few group roles for most purposes beyond the individual tailored grants. regards, tom lane
В списке pgsql-hackers по дате отправления: