Marc G. Fournier wrote:
> On Tue, 11 Apr 2006, Joshua D. Drake wrote:
>
> >
> >> Can you guarantee unequivocally that there are absolutely not security
> >> issues in plpgsql?
> >
> > Can you guarantee unequivocally that there are absolutely not security
> > issues
> > in PostgreSQL?
>
> No, b
: [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 m
> 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 sig
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 wor
On Wed, Apr 12, 2006 at 12:32:52PM +0200, Peter Eisentraut wrote:
> Am Dienstag, 11. April 2006 23:20 schrieb Tom Lane:
> > In the end it's only one small component of security, but any
> > security expert will tell you that you take all the layers of
> > security that you can get.
>
> I think wha
>
> I wonder if Oracle ever recommended disabling PL/SQL (not to
> mention MS Transact-SQL)...
>
Don't know abiout Oracle, but you can't disable Transact-SQL in SQL
Server 7.0 or 2000 (don't know about 2003^h5) because Enterprise Manager
and sp_help* require it.
And +1 for not installing plpgs
Dave Page wrote:
Keeping PostgreSQL as secure as possible out of the box pretty much
requires us to do the same in my mind - if an major feature such as
pl/pgsql is easy for the user to enable should they want it, then it
should be disabled by default to minimise the number of attack vectors
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Peter Eisentraut
> Sent: 12 April 2006 11:33
> To: pgsql-hackers@postgresql.org
> Cc: Tom Lane; David Fetter; Jim C. Nasby; Joshua D. Drake;
> [EMAIL PROTECTED]
> Sub
Am Dienstag, 11. April 2006 23:20 schrieb Tom Lane:
> In the end it's only one small component of security, but any security
> expert will tell you that you take all the layers of security that you
> can get.
I think what the security experts are saying is that you need a thorough
evaluation of a
Neil,
> 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
> pl/pgsql functions without taking any additional steps. Non-superusers
> could be given access to pl/pgsql via a simple GRANT -- either for all
>
> 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
> pl/pgsql functions without taking any additional steps. Non-superusers
> could be given access to pl/pgsql via a simple GRANT
On Tue, Apr 11, 2006 at 03:43:56PM -0700, Joshua D. Drake wrote:
> On Tue, 2006-04-11 at 19:35 -0300, Marc G. Fournier wrote:
> > On Tue, 11 Apr 2006, Joshua D. Drake wrote:
> >
> > >
> > >> No, but does that mean we should increase the potential by adding in
> > >> something that not everyone tha
On Tue, 2006-04-11 at 19:35 -0300, Marc G. Fournier wrote:
> On Tue, 11 Apr 2006, Joshua D. Drake wrote:
>
> >
> >> No, but does that mean we should increase the potential by adding in
> >> something that not everyone that runs PostgreSQL actually uses?
> >
> > Using this argument I could say that
On Tue, 11 Apr 2006, Joshua D. Drake wrote:
No, but does that mean we should increase the potential by adding in
something that not everyone that runs PostgreSQL actually uses?
Using this argument I could say that we don't need primary keys, foreign
keys, views or rules. Especially the latte
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
On 2006-04-11, Tom Lane <[EMAIL PROTECTED]> wrote:
> More realistically, though, the theoretical point that you can do
> arbitrary calculations by turning loops into recursive SQL functions is
> mostly just theoretical,
It's not at all theoretical. The very practical problem of trying to write
cod
On 2006-04-11, Tom Lane <[EMAIL PROTECTED]> wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
>> I don't get your not getting this 'cause you're a very smart guy. Are
>> you under the impression that an attacker will stop because he has to
>> try a few times?
>
> No, I'm saying that having access
> No, but does that mean we should increase the potential by adding in
> something that not everyone that runs PostgreSQL actually uses?
Using this argument I could say that we don't need primary keys, foreign
keys, views or rules. Especially the latter 3 ;).
Sincerely,
Joshua D. Drake
>
Tom Lane wrote:
In the end it's only one small component of security, but any security
expert will tell you that you take all the layers of security that you
can get. If you don't need a given bit of functionality, it shouldn't
get installed.
I think any security expert would say that if let no
On Tue, Apr 11, 2006 at 05:20:02PM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > I don't get your not getting this 'cause you're a very smart guy.
> > Are you under the impression that an attacker will stop because he
> > has to try a few times?
>
> No, I'm saying that havi
On Tue, 11 Apr 2006, Joshua D. Drake wrote:
Can you guarantee unequivocally that there are absolutely not security
issues in plpgsql?
Can you guarantee unequivocally that there are absolutely not security issues
in PostgreSQL?
No, but does that mean we should increase the potential by add
Are there are more possibilities for some bug in the plpgsql engine to allow an
exploit: actually changing the stack through a buffer overflow, or a bug in an
intrinsic function, or allowing an injection that crosses some privilege
boundary, via someone else's EXECUTE?
It's a lot easier to ver
David Fetter <[EMAIL PROTECTED]> writes:
> I don't get your not getting this 'cause you're a very smart guy. Are
> you under the impression that an attacker will stop because he has to
> try a few times?
No, I'm saying that having access to a PL renders certain classes of
attacks significantly mo
On Tue, Apr 11, 2006 at 05:01:17PM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Tue, Apr 11, 2006 at 04:35:05PM -0400, Tom Lane wrote:
> >> More realistically, though, the theoretical point that you can do
> >> arbitrary calculations by turning loops into recursive SQL
>
David Fetter <[EMAIL PROTECTED]> writes:
> On Tue, Apr 11, 2006 at 04:35:05PM -0400, Tom Lane wrote:
>> More realistically, though, the theoretical point that you can do
>> arbitrary calculations by turning loops into recursive SQL functions
>> is mostly just theoretical, and the reason is that you
On Tue, Apr 11, 2006 at 04:35:05PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Rather than debate how turing complete SQL is, look at the real
> > issue: is a compromised system with plPGSQL installed more
> > dangerous than a compromised system without plPGSQL. As far a
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Rather than debate how turing complete SQL is, look at the real issue:
> is a compromised system with plPGSQL installed more dangerous than a
> compromised system without plPGSQL. As far as I can see, it's not.
You're disregarding the possibility that p
On Mon, Apr 10, 2006 at 11:02:50PM -0700, David Fetter wrote:
> On Tue, Apr 11, 2006 at 12:47:03AM -0400, Tom Lane wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > > What does enabling plpgsql do via access that you can't just do from an
> > > SQL query?
> >
> > SQL isn't Turing-compl
Richard Huxton wrote:
Andrew - Supernews wrote:
On 2006-04-11, Tom Lane <[EMAIL PROTECTED]> wrote:
I don't feel a need to offer specific examples as requested by Andrew.
Why not? You're basing your entire argument on a false premise (that
pl/pgsql is more powerful than SQL); I can provide spe
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
What does enabling plpgsql do via access that you can't just do from an
SQL query?
SQL isn't Turing-complete --- plpgsql is. So if our would-be hacker has
a need to do some computation incidental to his hack, he can certainly
get i
Can you guarantee unequivocally that there are absolutely not security
issues in plpgsql?
Can you guarantee unequivocally that there are absolutely not security
issues in PostgreSQL?
I believe Tom's point is that it is not possible to do so, and, since
plpgsql isn't something that all ap
On 2006-04-11, Richard Huxton wrote:
> Andrew - Supernews wrote:
>> On 2006-04-11, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> I don't feel a need to offer specific examples as requested by Andrew.
>>
>> Why not? You're basing your entire argument on a false premise (that
>> pl/pgsql is more powerful
Andrew - Supernews wrote:
On 2006-04-11, Tom Lane <[EMAIL PROTECTED]> wrote:
I don't feel a need to offer specific examples as requested by Andrew.
Why not? You're basing your entire argument on a false premise (that
pl/pgsql is more powerful than SQL); I can provide specific examples of
why t
On 2006-04-11, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> What does enabling plpgsql do via access that you can't just do from an
>> SQL query?
>
> SQL isn't Turing-complete
SQL with the ability to create recursive functions, as exists in pg, is
certain
On Tue, Apr 11, 2006 at 12:47:03AM -0400, Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > What does enabling plpgsql do via access that you can't just do from an
> > SQL query?
>
> SQL isn't Turing-complete
With all due respect, SQL *is* Turing-complete. Here's a little demo
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> What does enabling plpgsql do via access that you can't just do from an
> SQL query?
SQL isn't Turing-complete --- plpgsql is. So if our would-be hacker has
a need to do some computation incidental to his hack, he can certainly
get it done in plpgs
On Mon, 10 Apr 2006, Joshua D. Drake wrote:
Tom Lane wrote:
Andrew - Supernews <[EMAIL PROTECTED]> writes:
On 2006-04-10, Bruce Momjian wrote:
[ security ]
It actually is the reason I have heard.
And it was duly debunked.
That is the reasoning, and personally I agree with it. You don'
Tom Lane wrote:
Andrew - Supernews <[EMAIL PROTECTED]> writes:
On 2006-04-10, Bruce Momjian wrote:
[ security ]
It actually is the reason I have heard.
And it was duly debunked.
That is the reasoning, and personally I agree with it. You don't leave
sharp objects sitting around if you ha
On 2006-04-11, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> On 2006-04-10, Bruce Momjian wrote:
[ security ]
>>> It actually is the reason I have heard.
>
>> And it was duly debunked.
>
> That is the reasoning, and personally I agree with it. You do
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2006-04-10, Bruce Momjian wrote:
>>> [ security ]
>> It actually is the reason I have heard.
> And it was duly debunked.
That is the reasoning, and personally I agree with it. You don't leave
sharp objects sitting around if you have no need to
On 2006-04-10, Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> > This is similar to the fact we don't include plpgsql by default in
>> > databases, for the same reason,
[the reason being "security"]
>>
>> I doubt that that is really the reason.
>
> It actually is the reason I have heard.
And i
41 matches
Mail list logo
