Joel Jacobson <j...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
