Re: GRANT EXECUTE ON FUNCTION foo() TO bar();

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

In response to

Responses

Browse pgsql-hackers by date

  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