[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