Eric Lauzon wrote:
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Merlin Moncure
Sent: 12 avril 2006 12:22
To: Neil Conway
Cc: Tom Lane; David Fetter; Jim C. Nasby; Joshua D. Drake;
[EMAIL PROTECTED]; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] plpgsql by default
On 4/11/06, Neil Conway <[EMAIL PROTECTED]> wrote:
On Tue, 2006-04-11 at 17:20 -0400, Tom Lane wrote:
No, I'm saying that having access to a PL renders certain
classes of
attacks significantly more efficient. A determined attacker with
unlimited time may not care, but in the real world, security is
relative.
That's a fair point.
Perhaps a compromise would be to enable pl/pgsql by
default, but not
grant the USAGE privilege on it. This would allow
superusers to define
One way to circumvent the hassle of having to create
the language is to create the database from a template
that has the language , hence semi-default plpgsql handler
by "default".
On the security side, if you implement strong ACLS on the data
manipulation
if the database is compromised to a level where a low priviliged user
database access
is compromised there shouldn't be any danger toward having them using
SQL or plpgsql.
The dark side of this could be some type of privilege escalation scheme
present
inside postgresql.
As example MS-SQL xp_* stored proc, are a vulnerability vector if the
compromised user
can execute them.
So if by default the attacked application is running as the "postgres"
user, what will you do to
prevent them from manipulating internal's? :)
This is just a little safer than surfing the internet with MSSQL
installed and the sa user having no password :-)
I wonder if a less-privileged user should be present in the database by
default, with some advise to use that user instead of postgres for
standard connections. I wouldn't be surprised if >80 % of win32 pgsql
installations have a single user only...
Regards,
Andreas
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
