Re: [HACKERS] GRANT EXECUTE ON FUNCTION foo() TO bar(); - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] GRANT EXECUTE ON FUNCTION foo() TO bar();
Date
Msg-id CAFj8pRC8crCE7Bgf=x6ic859FkNYH1YkCtpURMDyNoRxqHFtkw@mail.gmail.com
Whole thread Raw
In response to [HACKERS] GRANT EXECUTE ON FUNCTION foo() TO bar();  (Joel Jacobson <joel@trustly.com>)
Responses Re: [HACKERS] GRANT EXECUTE ON FUNCTION foo() TO bar();
List pgsql-hackers


2017-02-22 8:06 GMT+01:00 Joel Jacobson <joel@trustly.com>:
Hi Hackers,

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. 

This would be useful for functions that are not supposed to be used
manually by any human or any other function(s) than the few places
where the function makes sense to use.

Thoughts?

I had similar idea. The possibility to specify a list of functions can have a performance impact when ACL can be too long.

Just idea - what is based on idea "using schema like package". We can introduce new kind of functions X, that cannot be executed on toplevel - and can be executed only from standard functions defined in same schema.

Usage of X functions can be locked in schema.

It allow similar functionality to your proposal, but the check can be faster - and you don't need to maintain list of enabled caller functions.

Regards

Pavel


/Joel


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Replication vs. float timestamps is a disaster
Next
From: Joel Jacobson
Date:
Subject: Re: [HACKERS] GRANT EXECUTE ON FUNCTION foo() TO bar();