Re: RI permission problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Kyle <kyle(at)actarg(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: RI permission problem
Date: 2001-05-08 04:55:59
Message-ID: 27411.989297759@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Kyle writes:
>> Shouldn't the select access to the view trickle down to subordinate select functions?

> I would think not.

I agree with Peter. If user A creates a view that includes a call of a
function written by user B, does user A want user B's function to run
with all of user A's permissions? Not if he's adequately paranoid.
The function could do all sorts of damage above and beyond its
advertised task.

The correct solution to this is to allow a function to run with its
owner's permissions (if the owner wants to mark it setuid). In your
example, func_v1 and func_v2 should have permission to read atab_v1
and atab_v2 in their own right, independently of who calls them.

This does bring up the thought that we might like to control who can
call func_v1 and func_v2, however (by analogy to execute permissions
on Unix programs). We have ACLs for tables, but none yet for
functions...

regards, tom lane

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Haywood J'Bleauxmie 2001-05-08 07:36:14 left join syntax
Previous Message Oliver Elphick 2001-05-07 21:05:18 Re: General ISA and Foreign Key