[postgis-devel] estimated_extent & pg_statistic
strk at refractions.net
strk at refractions.net
Mon Mar 13 02:57:42 PST 2006
On Wed, Mar 08, 2006 at 05:39:09PM -0000, Mark Cave-Ayland wrote:
> > -----Original Message-----
> > From: postgis-devel-bounces at postgis.refractions.net [mailto:postgis-devel-
> > bounces at postgis.refractions.net] On Behalf Of strk at refractions.net
> > Sent: 06 March 2006 11:57
> > To: 'PostGIS Development Discussion'
> > Subject: Re: [postgis-devel] estimated_extent & pg_statistic
>
>
> Hi strk,
>
> (cut)
>
> > I'd rather avoid adding another view.
>
> Is there any particular reason why views cause a problem?
>
> I've attached a patch for Martin's case that marks the estimated_extent()
> function as SECURITY DEFINER and implements an access control check using
> has_table_privilege. The new behaviour is that if a user u1 creates a
> geometry column, user u1 can now call estimated_extent(), but a user u2 who
> does not have SELECT permissions on the target table will not be able to
> call estimated_extent() on user u1's table.
>
> The main downside with this approach is that it appears PostgreSQL 7.2
> doesn't support SECURITY DEFINER, and so non-superusers would not be able to
> get around this issue (then again, if you are still running a 7.2 series
> database in production you probably have a lot more pressing issues...)
I applied your patch with a small modification of #defines in postgis.sql.in.
As you noticed we don't need SECURITY DEFINER for builds against PGSQL <800
so the 'downside' seems to be disapppeared.
Any test welcome with different pgsql versions and access control layout.
--strk;
More information about the postgis-devel
mailing list