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. Th
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
---
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 specifi
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 anything
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 Herrerahttp://www.CommandPro
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 tryin
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 prett
>>> 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 co
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 superus
"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 o
-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 i
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 ma
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 revo
-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
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 inclu
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 brai
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 c
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 language
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
> -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: [
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 never
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:
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 installatio
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 custom
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-c
-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 neit
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
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.
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
tem
-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
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 examp
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 th
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 te
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 u
"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 oper
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 m
>
> 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.
> >
> >
-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
-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)
"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
---
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 p
-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 clo
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 pl
-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 clo
-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 exam
"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 wi
-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
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 c
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) a
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 thin
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
ra
-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?
>
> http://markmail.org
-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
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 su
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
t
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 t
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,
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?
Folks,
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.
Cheers,
David.
--
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davi
59 matches
Mail list logo
