From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joel Jacobson <joel(at)trustly(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: GRANT EXECUTE ON FUNCTION foo() TO bar(); |
Date: | 2017-02-22 13:18:39 |
Message-ID: | 20187.1487769519@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joel Jacobson <joel(at)trustly(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2017-02-22 13:31:40 | Re: GRANT EXECUTE ON FUNCTION foo() TO bar(); |
Previous Message | Ashutosh Bapat | 2017-02-22 12:58:19 | Re: Partitioned tables and relfilenode |