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

From: Joel Jacobson <joel(at)trustly(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GRANT EXECUTE ON FUNCTION foo() TO bar();
Date: 2017-02-22 13:31:40
Message-ID: CAASwCXfmOhj8iL853zS0-nthqhMjX-mxNAbzOpFq75BVCeMCDQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 22, 2017 at 2:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I think this is really *not* a good idea. The entire permissions model
> is built around granting permissions to roles, by other roles.

My bad. I shouldn't have proposed the idea on how to achieve/implement the idea.

I should instead just have presented the idea without suggesting to
use the permissions model.

Do you think it's a bad idea in general? Or is it just the idea of
using the permissions model for the purpose that is a bad idea?

If it's a good idea apart from that, then maybe we can figure out some other
more feasible way to control what functions can call what other functions?

> 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.

I think that approach is not very user-friendly, but maybe it can be
made more convenient if adding syntactic sugar to allow doing it all
in a single command?

Or maybe there is some other way to implement it without the permissions model.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2017-02-22 13:38:34 Cleanup: avoid direct use of ip_posid/ip_blkid
Previous Message Tom Lane 2017-02-22 13:18:39 Re: GRANT EXECUTE ON FUNCTION foo() TO bar();