Re: problem permission on view

Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
> 
>>As said, I discussed this with Gaetano on IRC, and am not sure why things are
>>set up the way they are.    If a user has permission on a view, shouldn't 
>>that include permission on any functions executed by the view?    If not, why
>>not?
> 
> 
> See prior discussions.  The two stumbling blocks I can recall are:
> 
> 1. Not breaking the ability of functions called by views to tell who the
> real user is --- see the filtering in the pg_statistic view for a handy
> real-world example.  This constrains the possible design solutions.
> 
> 2. Given the flexibility of the rule rewrite system, it's not unlikely
> that a user could find a way to execute any function invoked by a rule
> on data of his choosing.  This is a bad idea if the function should not
> ordinarily be his to call.
> 
> (Enlarging on point 2: there are no views.  There are only rules, and
> any proposed solution has to be cast in terms of what happens with
> arbitrary rules.)
> 
> I'm not saying we'll never do this, but I am saying that the topic has
> been visited before and no one's come up with an acceptable design.

Trust me, manage 167 views and 341 functions is a night mare in this way,
considering that I public some views and functions with a sort of XML-RPC.

As I already wrote on IRC, giving the executable permission on a table
( with security definer ) I allow users to call the function with any value
instead of values only presents in the view. I think this is a big limitation.
I'd like to fix this by myself but for lack of time and lack of postgres
code knowledge I'm stuck.

Regards
Gaetano Mendola