On Thursday 21 February 2008 21:33, Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
On Thursday 21 February 2008 11:36, Tom Lane wrote:
Would it satisfy people if plpgsql were in postgres, but neither
template DB, after initdb?
No, the real-world use-case we're trying to satisfy
Robert Treat wrote:
They are then free to muck about that database, installing anything
they want, but they cannot load any procedural languages since they
only have non-superuser accounts.
Except that they can in 8.3.
--
Alvaro Herrera
Robert Treat wrote:
There are a lot of people who have a database provider of some sort who
creates a database for them, giving them ownership of that specific database,
with pg_hba.conf specifying connection only to that db. They are then free to
muck about that database, installing
Robert Treat [EMAIL PROTECTED] writes:
On Thursday 21 February 2008 21:33, Tom Lane wrote:
So it's still 100% unclear to me who we are catering to.
There are a lot of people who have a database provider of some sort who
creates a database for them, giving them ownership of that specific
Tom,
That argument *was* valid ... before 8.3. Nowadays non-superuser DB
owners can install trusted PLs in their DBs by themselves. (At least
by default.) So I'm still unconvinced that we need more changes.
I agree.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
On Tuesday 26 February 2008 12:20, Andrew Dunstan wrote:
Robert Treat wrote:
There are a lot of people who have a database provider of some sort who
creates a database for them, giving them ownership of that specific
database, with pg_hba.conf specifying connection only to that db. They
Am Freitag, 22. Februar 2008 schrieb Dave Page:
I know I'm gonna regret wading in on this, but in my mind this is akin
to one of the arguments for including tsearch in the core server -
namely that too many brain dead hosting providers won't add a contrib
module or anything else in a
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
On Thursday 21 February 2008 11:36, Tom Lane wrote:
Would it satisfy people if plpgsql were in postgres, but neither
template DB, after initdb?
No, the real-world use-case we're trying to satisfy is hosted and/or
locked-down
Joshua D. Drake wrote:
I probably shouldn't be answering this at two in the morning but... As I
understand it in a hosted environment it is quite common that a
superuser will do this:
create database foo owner foo;
Database foo would get plpgsql (as would user foo) at that point
Tom Lane wrote:
Certainly you can cause massive DOS-type problems in plain SQL without
any access to plpgsql, but that type of juvenile delinquency isn't what
concerns me. What I'm worried about is whether plpgsql isn't a useful
tool for the sort of professional who would much rather you
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Andrew Dunstan
Sent: Friday, February 22, 2008 9:28 AM
To: Tom Lane
Cc: Joshua D. Drake; Greg Sabino Mullane; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Including PL/PgSQL
On Fri, 22 Feb 2008 07:37:55 +
Dave Page [EMAIL PROTECTED] wrote:
I know I'm gonna regret wading in on this, but in my mind this is akin
to one of the arguments for including tsearch in the core server -
namely that too many brain dead hosting providers won't add a contrib
module or
Roberts, Jon wrote:
However, you can not create anything in Oracle without being given
permission to create it. The notion that you can create a function
because you have connect rights to the database is foreign to me.
Connect should mean connect, not connect AND create.
Include the
Andrew Dunstan [EMAIL PROTECTED] writes:
Roberts, Jon wrote:
However, you can not create anything in Oracle without being given
permission to create it. The notion that you can create a function
because you have connect rights to the database is foreign to me.
Connect should mean connect,
On Fri, 22 Feb 2008, D'Arcy J.M. Cain wrote:
On Fri, 22 Feb 2008 07:37:55 +
Dave Page [EMAIL PROTECTED] wrote:
I know I'm gonna regret wading in on this, but in my mind this is akin
to one of the arguments for including tsearch in the core server -
namely that too many brain dead
Speaking as someone who is all about packaging PG for end users, and
in truth could care less what is included by default, I can tell you
that the top 3 requests I get from end users that don't want to muck
around with building and installing themselves are for pl/pgsql,
tsearch2 (now
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
D'Arcy J.M. Cain wrote:
Besides, proof that it would do no extra harm is hardly a strong
argumet for including it. Given how easy it is to add it to any DB
that needs it, I fail to see why we should add it by default.
Because we're not
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
For example, since we don't support temp functions, we should probably
ban the creation of functions in temp schemas (which I found was possible).
What for? If you don't want someone to use a language, you should
either
Andrew Dunstan [EMAIL PROTECTED] writes:
So on reflection I'm now inclined to say we should not change what we
are now doing, which is simply to allow the db owner to install and
control access to the language.
+1. It's worth pointing out here that we just changed the rules in 8.3
to make
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 22 Feb 2008 12:31:14 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
So on reflection I'm now inclined to say we should not change what
we are now doing, which is simply to allow the db owner to install
Joshua D. Drake [EMAIL PROTECTED] writes:
Not really sure what to think here. On the one hand I agree that since
the dbowner can load it at their leisure its cool. On the other hand I
wonder why we continue to add extra unnecessary steps to our life. Yes,
it is a simple step but it is one that
On Fri, Feb 22, 2008 at 11:30:28AM -0500, Andrew Satori wrote:
As a packager, I respond to customer pressure by solving their needs,
so I pre-package those contrib's as needed, but I do feel that they
should be reviewed as potential core inclusions
Given that you don't need to be superuser
On Fri, Feb 22, 2008 at 10:09 AM, in message [EMAIL PROTECTED],
Andrew Dunstan [EMAIL PROTECTED] wrote:
Roberts, Jon wrote:
However, you can not create anything in Oracle without being given
permission to create it. The notion that you can create a function
because you have connect rights
Peter,
Half of this entire thread is content-free because the participants are
apparently not aware that a database owner can add plpgsql *without*
superuser privileges.
Yep. Among 280+ new features for 8.3, most of us missed that patch.
Thanks, Jeremy!
All, I think Jeremy's patch pretty
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I grow weary of repeating this: it's not about resource consumption, nor
about potential security holes in plpgsql itself. It's about handing
attackers the capability to further exploit *other* security holes.
Well, without specific
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 21 Feb 2008 17:34:06 -
Greg Sabino Mullane [EMAIL PROTECTED] wrote:
There are so many simple ways to do bad things /without/ plpgsql, I
just don't see how the theoretical harm in it being used as an attack
vector even comes close to
Tom,
I grow weary of repeating this: it's not about resource consumption, nor
about potential security holes in plpgsql itself. It's about handing
attackers the capability to further exploit *other* security holes.
Well, without specific examples, I'm not sure I understand what plpgsql
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 21 Feb 2008 17:34:06 -
Greg Sabino Mullane [EMAIL PROTECTED] wrote:
There are so many simple ways to do bad things /without/ plpgsql, I
just don't see how the theoretical harm in it being used as an attack
vector even comes close to
Joshua D. Drake wrote:
Notice that user foo is not a super user. Now I log into
PostgreSQL and connect to the postgres database (the super users
database) as the non privileged user foo. The user foo in theory
has *zero* rights here accept that he can connect.
That's not true. The
Joshua D. Drake [EMAIL PROTECTED] writes:
In one fell swoop I could crash *any* postgresql database running 8.2.6
or below (I haven't tested this on 8.3).
Uh, I seem to have missed where the crash was in this example?
regards, tom lane
---(end
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 21 Feb 2008 13:33:44 -0500
Andrew Dunstan [EMAIL PROTECTED] wrote:
That's not true. The public schema has public UC privs, and always
has had.
This disproves my point how?
There is nothing surprising (expect possibly to you) here.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 21 Feb 2008 13:38:50 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
In one fell swoop I could crash *any* postgresql database running
8.2.6 or below (I haven't tested this on 8.3).
Uh, I seem to
Joshua D. Drake wrote:
Notice that user foo is not a super user. Now I log into
PostgreSQL and connect to the postgres database (the super users
database) as the non privileged user foo. The user foo in theory
has *zero* rights here accept that he can connect.
That's not
On Thu, Feb 21, 2008 at 10:43:27AM -0800, Joshua D. Drake wrote:
often. It is poor implementation and proof that the theoretical
security implications that are being brought up in this thread are far
from the practical reality.
We have this hole over here for historical reasons, so let's
Joshua D. Drake [EMAIL PROTECTED] writes:
Uh, I seem to have missed where the crash was in this example?
I wasn't willing to dump my machine. However I could:
A. Exhaust all resources
B. Fill up my hard drive
C. Render the application unusable for other users
D. Lock out DDL operations by
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 21 Feb 2008 13:33:44 -0500
Andrew Dunstan [EMAIL PROTECTED] wrote:
That's not true. The public schema has public UC privs, and always
has had.
This disproves my point how?
You stated that this
Tom Lane wrote:
Anyway, as I said before, I don't object to installing plpgsql by
default. What I do object to is installing it in a way that makes it
difficult for the DBA to remove it, as would be the case if it were in
template0 for example.
... which means it can't be installed in
On Thu, 21 Feb 2008 14:14:48 -0500
Andrew Sullivan [EMAIL PROTECTED] wrote:
On Thu, Feb 21, 2008 at 10:43:27AM -0800, Joshua D. Drake wrote:
often. It is poor implementation and proof that the theoretical
security implications that are being brought up in this thread are far
from the
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Anyway, as I said before, I don't object to installing plpgsql by
default. What I do object to is installing it in a way that makes it
difficult for the DBA to remove it, as would be the case if it were in
template0 for example.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 21 Feb 2008 14:15:28 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Anyway, as I said before, I don't object to installing plpgsql by
default. What I do object to is installing it in a way that makes it
difficult for the DBA to remove it, as
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Anyway, as I said before, I don't object to installing plpgsql by
default. What I do object to is installing it in a way that makes it
difficult for the DBA to remove it, as would be the case if it were in
On Thursday 21 February 2008 11:36, Tom Lane wrote:
Would it satisfy people if plpgsql were in postgres, but neither
template DB, after initdb? T
No, the real-world use-case we're trying to satisfy is hosted and/or
locked-down installations where the developer doesn't have superuser access.
Josh Berkus [EMAIL PROTECTED] writes:
On Thursday 21 February 2008 11:36, Tom Lane wrote:
Would it satisfy people if plpgsql were in postgres, but neither
template DB, after initdb?
No, the real-world use-case we're trying to satisfy is hosted and/or
locked-down installations where the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Thursday, February 21, 2008 21:33:03 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Josh Berkus [EMAIL PROTECTED] writes:
On Thursday 21 February 2008 11:36, Tom Lane wrote:
Would it satisfy people if plpgsql were in postgres, but neither
On Fri, Feb 22, 2008 at 2:33 AM, Tom Lane [EMAIL PROTECTED] wrote:
Josh Berkus [EMAIL PROTECTED] writes:
On Thursday 21 February 2008 11:36, Tom Lane wrote:
Would it satisfy people if plpgsql were in postgres, but neither
template DB, after initdb?
No, the real-world use-case we're
On Tue, Feb 19, 2008 at 08:37:51PM -0500, Andrew Dunstan wrote:
The way I intended to do it would indeed allow it to be undone simply by
executing 'drop language plpgsql' in template1.
Why isn't it enough that administrators can do CREATE LANGUAGE plpgsql in
template1?
I think this is
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
The way I intended to do it would indeed allow it to be undone
simply by executing 'drop language plpgsql' in template1.
Why isn't it enough that administrators can do CREATE LANGUAGE
plpgsql in template1?
Because people do not have the
Greg Sabino Mullane [EMAIL PROTECTED] writes:
I'm not sure I understand the security implications of turning plpgsql on:
has there been some security concerns in the past? Does having access
to plpgsql really faciliate an attacker that much above what they might
already be capable of without
On Tue, Feb 19, 2008 at 12:11:05PM -0500, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
Let's put PL/PgSQL in template1 by default, as some downstream
packagers are already doing. If someone really must remove it,
they can still do that.
This has been proposed before, and
David Fetter [EMAIL PROTECTED] writes:
Let's put PL/PgSQL in template1 by default, as some downstream
packagers are already doing. If someone really must remove it, they
can still do that.
This has been proposed before, and rejected before. Have you got any
new arguments?
David Fetter [EMAIL PROTECTED] writes:
On Tue, Feb 19, 2008 at 12:11:05PM -0500, Tom Lane wrote:
This has been proposed before, and rejected before. Have you got
any new arguments?
The longer it's been since the last vuln in PL/PgSQL, the harder it is
to argue for having it not be there by
Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
On Tue, Feb 19, 2008 at 12:11:05PM -0500, Tom Lane wrote:
This has been proposed before, and rejected before. Have you got
any new arguments?
The longer it's been since the last vuln in PL/PgSQL, the harder it is
to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 19 Feb 2008 18:13:53 -0500
Andrew Dunstan [EMAIL PROTECTED] wrote:
I am having trouble locating the previous thread - can someone please
point me at it?
I am having trouble finding one that makes a cohesive argument against
but here we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 19 Feb 2008 15:25:44 -0800
Neil Conway [EMAIL PROTECTED] wrote:
On Tue, 2008-02-19 at 18:13 -0500, Andrew Dunstan wrote:
I am having trouble locating the previous thread - can someone
please point me at it?
On Tue, 2008-02-19 at 18:13 -0500, Andrew Dunstan wrote:
I am having trouble locating the previous thread - can someone please
point me at it?
http://markmail.org/message/kyjbj5qovadfoe3w
-Neil
---(end of broadcast)---
TIP 7: You can help
Neil Conway wrote:
On Tue, 2008-02-19 at 18:13 -0500, Andrew Dunstan wrote:
I am having trouble locating the previous thread - can someone please
point me at it?
http://markmail.org/message/kyjbj5qovadfoe3w
Thanks. The only significant problem I saw mentioned other than the
Andrew Dunstan [EMAIL PROTECTED] writes:
Thanks. The only significant problem I saw mentioned other than the
rather ephemeral security issues was the one regarding statically linked
postgres.
Nothing like establishing one's point by carefully ignoring all the
nontrivial problems.
I think
Tom Lane wrote:
Still and all, I will hold still for having it be installed by default
as long as there is a simple way for the DBA to change that default
--- let's say, roughly as simple as it is now for the DBA to make it the
default if he wishes (ie create language plpgsql in template1)
58 matches
Mail list logo
