Re: pl/pgsql enabled by default - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: pl/pgsql enabled by default
Date
Msg-id 1115459227.3517.85.camel@localhost.localdomain
Whole thread Raw
In response to Re: pl/pgsql enabled by default  (Neil Conway <neilc@samurai.com>)
Responses Re: pl/pgsql enabled by default  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
On Sat, 2005-05-07 at 14:52 +1000, Neil Conway wrote:
> Andrew Sullivan wrote:
> > Sure it is.  "Don't enable anything you don't need," is the first
> > security rule.  Everything is turned off by default.  If you want it,
> > enable it.
> 
> So would you have us disable all the non-essential builtin functions? 
> (Many of which have has security problems in the past.) What about the 
> builtin encoding conversions, non-btree indexes, or a myriad of features 
> that not all users need or use?

I support Andrew's comment, though might reword it to 
"Don't enable anything that gives users programmable features or user
exits by default".

You can't use the builtin encoding functions or non-btree indexes to
access things you are not supposed to.

Anything that is *always* there provides a platform for malware. 

I'm not really sure what is wrong with the CREATE LANGUAGE statement
anyway - it is dynamically accessible, so doesn't require changes that
effect other database instance users. I do understand the wish to make
the lives of admins easier, but this isn't a hard thing to do...

> What makes sense for the default configuration of an operating system 
> (which by nature must be hardened against attack) does not necessarily 
> make sense for a database system.

Security is everybody's job, not just the OS guys. Personally, I forget
that constantly, but the principle seems clear.

Best Regards, Simon Riggs




pgsql-hackers by date:

Previous
From: Jochem van Dieten
Date:
Subject: Re: rendezvous
Next
From: Neil Conway
Date:
Subject: Re: pl/pgsql enabled by default