Re: advisory locks and permissions

On Fri, Sep 22, 2006 at 12:03:46PM -0400, AgentM wrote:
> 
> On Sep 22, 2006, at 11:26 , Merlin Moncure wrote:
> 
> >On 9/22/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>Stephen Frost <sfrost@snowman.net> writes:
> >>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> >>>> An admin who is concerned about this can revoke public access  
> >>on the
> >>>> functions for himself ... but should that be the default out-of- 
> >>the-box
> >>>> configuration?  I feel more comfortable with saying "you have  
> >>to turn
> >>>> on this potentially-dangerous feature" than with saying you  
> >>have to turn
> >>>> it off.
> >>
> >>> I agree with having it turned off by default, at least in 8.2.
> >>
> >>Do we have a consensus to do this for 8.2?  Or are we going to  
> >>leave it
> >>as is?  Those are the only two realistic short-term options ...
> >
> >there are plenty of other potentially nasty things (like
> >generate_series and the ! operator).  why are advisory_locks handled
> >specially?   the way it stands right now is a user with command access
> >can DoS a server after five minutes of research on the web.
> >
> >however, if we decide to lock them,  it should be documented as such.
> >
> >advisory locks still show up as 'userlock' in the pg_locks view.  does
> >this matter?
> 
> I would be more worried about accidental collisions between  
> applications. The lock ranges will now need to be in their respective  
> application's configuration file in case of collision with another  
> app once developers really start using locks for IPC. Ideally, the  
> user-level lock functions would take strings instead of integers and  
> hash them appropriately, no? Otherwise, someone will end up  
> maintaining a registry of lock numbers in use. LISTEN doesn't use  
> integers.

This is why I suggested we set aside some range of numbers that should
not be used. Doing so would allow adding a better-managed
numbering/naming scheme in the future.
-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)