> -Original Message-
> From: Mark Pritchard [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 11:27 PM
> To: Dann Corbit; Neil Conway
> Cc: Justin Clift; Tom Lane; Christopher Kings-Lynne;
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] @(#) Mordred Labs advisory 0x0001:
> Buffer
On Tue, 20 Aug 2002 15:35, Dann Corbit wrote:
> Most computer virus problems are caused by buffer overrun. Someone
> decided it wasn't very important.
>
> Some computer viruses have caused billions of dollars in damage. Sounds
> important to me.
>
> "Please try our database. Someday, we hope to
> To simply decide not to fix it means:
> What I am saying is that there is nothing that could possibly be more
> important than fixing this, except some other known problem that could
> also cause billions of dollars worth of damage. Are there any such
> problems besides the buffer overrun prob
On Tue, 20 Aug 2002 15:22, Neil Conway wrote:
> I'd say the two issues are pretty different. IMHO, buffer overruns and
> similar security problems are just a special class of software bug
> (it's interesting to note that most of the buffer overruns have been
> found in the less-maintained parts of
> -Original Message-
> From: Neil Conway [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 10:48 PM
> To: Dann Corbit
> Cc: Neil Conway; Mark Pritchard; Justin Clift; Tom Lane;
> Christopher Kings-Lynne; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] @(#) Mordred Labs advisory 0x000
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> I read (in some other message) that this buffer overrun problem has been
> known for a very, very long time.
No, the problem you're referring to (cash_out() and friends) is *not*
a buffer overrun.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || P
> -Original Message-
> From: Neil Conway [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 10:42 PM
> To: Dann Corbit
> Cc: Neil Conway; Mark Pritchard; Justin Clift; Tom Lane;
> Christopher Kings-Lynne; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] @(#) Mordred Labs advisory 0x000
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> If you *know* of a buffer overrun, and simply decide not to fix it,
> that sounds very negligent to me.
*sigh*, no one is doing that, and it is pure negligence on your part
for replying to a thread that you clearly have not read.
Cheers,
Neil
--
Nei
The 'type_sanity' and 'domain' regression tests seem to fail with CVS
HEAD. Here's the diff:
*** ./expected/type_sanity.out Sun Aug 4 15:48:11 2002
--- ./results/type_sanity.out Tue Aug 20 01:32:35 2002
***
*** 16,22
SELECT p1.oid, p1.typname
FROM pg_type as p1
WHERE (p
> -Original Message-
> From: Neil Conway [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 19, 2002 10:22 PM
> To: Mark Pritchard
> Cc: Justin Clift; Tom Lane; Christopher Kings-Lynne;
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] @(#) Mordred Labs advisory 0x0001:
> Buffer overflow in
>
> As Tom pointed out, we've already had several releases without getting
> rid of this OPAQUE DOS bug, and as pointed out he also really doesn't
> have the patience for fixing it (yet).
>
> Was hoping we could get serious bugs fixed sooner rather than later,
> otherwise I'm afraid of us just addin
Mark Pritchard <[EMAIL PROTECTED]> writes:
> I believe its been said before, in this forum no less, that
> PostgreSQL should focus on its primary role as an RDBMS and not be
> paranoid about security. I believe it was the thread on SSL
> connections, and Tom suggested a simple ssh tunnel or vpn.
Hi Mark,
Mark Pritchard wrote:
>
> I believe its been said before, in this forum no less, that PostgreSQL should
> focus on its primary role as an RDBMS and not be paranoid about security. I
> believe it was the thread on SSL connections, and Tom suggested a simple ssh
> tunnel or vpn.
>
> Of
On Tue, 20 Aug 2002 13:40, Justin Clift wrote:
[snip]
> For example, thinking about something like the various ISP's around who
> host PostgreSQL databases; how much effort would it take to fix the
> vulnerabilities that let someone with remote access, but no ability to
> run a "trusted" language,
Thomas Lockhart wrote:
> > > Revert. The XLogDir change was incomplete and basically useless to
> > > start with ...
> > Yea, but it was tied into the PGXLOG commit. Thomas, what are we doing
> > with that?
>
> Why ask me?
Sorry, I mean XLOGDIR. Somehow I kept saying PGXLOG. Anyway, it is al
> > Revert. The XLogDir change was incomplete and basically useless to
> > start with ...
> Yea, but it was tied into the PGXLOG commit. Thomas, what are we doing
> with that?
Why ask me?
- Thomas
---(end of broadcast)---
TIP 4
Rod Taylor dijo:
> The simple fix is to drop the money type entirely as it serves few
> purposes -- but there are some who use it.
There are a lot of other functions that cause the same problem. Just
dropping or fixing cash_out is not the solution.
--
Alvaro Herrera ()
One man's impedance mi
Justin Clift <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This particular hole has been in *every* release since Postgres 1.01.
> How many releases have we known about this and still done a major
> release?
Several; a quick glance in the archives shows this has been on the TODO
list since 7.
On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
> > > I'd like to see something done about this fairly soon, but it's not
> > > happening for 7.3 ...
> >
> > Hang on, you seem to be suggesting we release a major new upgrade, with
> > major new functionality, knowing it contains a way t
> > I'd like to see something done about this fairly soon, but it's not
> > happening for 7.3 ...
>
> Hang on, you seem to be suggesting we release a major new upgrade, with
> major new functionality, knowing it contains a way to trivially crash
> the backend.
>
> Err.. hang on. What happened to
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
>> test=> select cash_words('-70');
>> Minus twenty one million four hundred seventy four thousand eight
>> hundred thirty six dollars and forty eight cents
> It doesn't crash - but it sure is giving the wrong answe
Tom Lane wrote:
>
> Justin Clift <[EMAIL PROTECTED]> writes:
> > Hang on, you seem to be suggesting we release a major new upgrade, with
> > major new functionality, knowing it contains a way to trivially crash
> > the backend.
>
> This particular hole has been in *every* release since Postgres
Justin Clift <[EMAIL PROTECTED]> writes:
> Hang on, you seem to be suggesting we release a major new upgrade, with
> major new functionality, knowing it contains a way to trivially crash
> the backend.
This particular hole has been in *every* release since Postgres 1.01.
I'm really not intereste
> Looks like cash_words is fixed in current CVS, so I guess in 7.2.1:
>
> Welcome to psql 7.3devel, the PostgreSQL interactive terminal.
>
> Type: \copyright for distribution terms
> \h for help with SQL commands
> \? for help on internal slash
Stephan Szabo wrote:
> > If don't understand. We already have a unique index on the SERIAL
> > column, so why bother rejecting an insert/update that supplies the
> > value? We need the column to be unique, and that is forced, but why
> > prevent _any_ unique value from being used.
>
> One reaso
Tom Lane wrote:
>
> Justin Clift <[EMAIL PROTECTED]> writes:
> > From the info still around, this looks to mean that the cash_words()
> > problem was fixed, but the cash_out() problem was harder to fix.
>
> > Tom/Bruce, is that correct?
>
> The cash_out problem can't really be fixed until we do
Done. Called libpq++.
---
Bruce Momjian wrote:
>
> Oh, sorry. I will do it now.
>
> ---
>
> Marc G. Fournier wrote:
> >
> > We're talking about li
On Mon, 19 Aug 2002, Bruce Momjian wrote:
> Joe Conway wrote:
> > Tom Lane wrote:
> > > Joe Conway <[EMAIL PROTECTED]> writes:
> > >>I agree 100%. If you want an index, unique constraint, or primary key on
> > >>a SERIAL, I think you should explicitly add it. SERIAL should give me a
> > >>column
Oh, sorry. I will do it now.
---
Marc G. Fournier wrote:
>
> We're talking about libpq++, not libpqxx :)
>
>
> On Mon, 19 Aug 2002, Bruce Momjian wrote:
>
> >
> > Actually, I think Jeroen T. Vermeulen <[EMAIL PROTECTED]
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Sorry to hear that this is the way it turned out. It is a bad precedent
> imho, and I see no way forward on my interest in this area. Hopefully
> someone else will pick it up; perhaps one of those so vehemently against
> the details of this?
I said I
Justin Clift <[EMAIL PROTECTED]> writes:
> From the info still around, this looks to mean that the cash_words()
> problem was fixed, but the cash_out() problem was harder to fix.
> Tom/Bruce, is that correct?
The cash_out problem can't really be fixed until we do something about
subdividing type
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I didn't follow the index part completely, but will heap and index pages
> have the version info in the same offset?
Sure, low byte of pd_pagesize.
> Will there be a way to easily identify an index page vs. a heap page.
There already is: heap pages ha
Justin Clift wrote:
> Christopher Kings-Lynne wrote:
> >
> > > On Tue, 20 Aug 2002, Justin Clift wrote:
> > >
> > > > Vince,
> > > >
> > > > Do you reckon it's worth you responding to "Sir Mordred" and pointing
> > > > out that he overstated the vulnerability?
> > >
> > > Not me. Tom (pref) or M
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> Has it actually been fixed?
I couldn't reproduce a problem with his example. The buffer size in
cash_words is awfully tight though --- it's dimensioned 128 which looks
like a round number rather than a carefully calculated one, and the
requ
Justin Clift wrote:
> Hi Vince,
>
> Glad he made the advisory for something there's a fix for. :)
Oh, I see he jumpe on cash_words() and didn't mention cash_out.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If yo
Vince Vielhaber wrote:
>
> Surprised it took this long.
Yes, me too, and it says the solution is to upgrade to 7.2.1. Nope.
> -- Forwarded message --
> Date: Mon, 19 Aug 2002 15:40:28 +
> From: Sir Mordred The Traitor <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject:
Yes, perhaps a bad precedent. I have very rarely done this. I do have
the patch here if anyone wants to use it. My guess is if someone
implements it, it will be done only in initdb, and use symlinks, which
you and Marc don't like, so we may be best leaving it undone for 7.3 and
returning with
I didn't follow the index part completely, but will heap and index pages
have the version info in the same offset? Will there be a way to
easily identify an index page vs. a heap page.
---
Tom Lane wrote:
> Manfred Koizar
We're talking about libpq++, not libpqxx :)
On Mon, 19 Aug 2002, Bruce Momjian wrote:
>
> Actually, I think Jeroen T. Vermeulen <[EMAIL PROTECTED]> should create the
> project. It is his code, and if he would add me as an admin, that would
> help. I am CC'ing him.
>
>
> -
Christopher Kings-Lynne wrote:
>
> > On Tue, 20 Aug 2002, Justin Clift wrote:
> >
> > > Vince,
> > >
> > > Do you reckon it's worth you responding to "Sir Mordred" and pointing
> > > out that he overstated the vulnerability?
> >
> > Not me. Tom (pref) or Marc would be the proper respondent.
>
>
> On Tue, 20 Aug 2002, Justin Clift wrote:
>
> > Vince,
> >
> > Do you reckon it's worth you responding to "Sir Mordred" and pointing
> > out that he overstated the vulnerability?
>
> Not me. Tom (pref) or Marc would be the proper respondent.
Has it actually been fixed?
Chris
--
Joe Conway wrote:
> Tom Lane wrote:
> > Joe Conway <[EMAIL PROTECTED]> writes:
> >>I agree 100%. If you want an index, unique constraint, or primary key on
> >>a SERIAL, I think you should explicitly add it. SERIAL should give me a
> >>column that automatically increments -- no more, no less.
>
Actually, I think Jeroen T. Vermeulen <[EMAIL PROTECTED]> should create the
project. It is his code, and if he would add me as an admin, that would
help. I am CC'ing him.
---
Marc G. Fournier wrote:
> On Sun, 18 Aug 2002
On Tue, 20 Aug 2002, Justin Clift wrote:
> Vince,
>
> Do you reckon it's worth you responding to "Sir Mordred" and pointing
> out that he overstated the vulnerability?
Not me. Tom (pref) or Marc would be the proper respondent.
>
> :-)
>
> Regards and best wishes,
>
> Justin Clift
>
>
> Tom Lan
Vince,
Do you reckon it's worth you responding to "Sir Mordred" and pointing
out that he overstated the vulnerability?
:-)
Regards and best wishes,
Justin Clift
Tom Lane wrote:
>
> Justin Clift <[EMAIL PROTECTED]> writes:
> > Glad he made the advisory for something there's a fix for. :)
>
On Sat, Aug 17, 2002 at 11:08:45PM -0400, Bruce Momjian wrote:
>
> integrate or move to gborg libpqxx, Pg:DBD
It's no longer my CVS home tree... Is there something I can/should
do for this?
Jeroen
---(end of broadcast)---
TIP 1: subscribe and
[EMAIL PROTECTED] (Florian Weimer) wrote
> Alvar Freude <[EMAIL PROTECTED]> writes:
>
>>> What about checking the input for backslash, quote,
>>> and double quote (\'")? If you are not taking care of those in
>>> input then crashing the backend is going to be the least of your
>>> worries.
>
CREATE CAST WITHOUT FUNCTION is capable of creating binary equivalences
that will crash the backend when used (eg, between pass-by-value and
pass-by-reference datatypes). The existing restriction that you must
own one of the datatypes hardly seems like an adequate permissions
check ... especially
foobar
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Neil Conway wrote:
Thomas Swan <[EMAIL PROTECTED]> writes:
1. create a user with createdb privilege.
2. create a database as that user (allowing that user full reign over
that particular db)
3. drop the createdb from the user.
4. pg_dumpall the databases to a single file
5. either
Thomas Swan <[EMAIL PROTECTED]> writes:
> 1. create a user with createdb privilege.
> 2. create a database as that user (allowing that user full reign over
> that particular db)
> 3. drop the createdb from the user.
> 4. pg_dumpall the databases to a single file
> 5. either use pg_restore or psql
Using pg_dump and pg_dumpall I ran into the following problems and had
addressed it earlier to this list with no response.
Using PostgreSQL 7.2.x
1. create a user with createdb privilege.
2. create a database as that user (allowing that user full reign over
that particular db)
3. drop the cre
Tom Lane <[EMAIL PROTECTED]> writes:
> Saying or implying that the developers don't care about data integrity
> does not enhance your credibility.
Sorry, my fault. Indeed, I didn't check carefully whether the people
who go a bit too far in downplaying the problem at hand are in fact
PostgreSQL
Florian Weimer <[EMAIL PROTECTED]> writes:
> That's the idea. It's the job of the database to guarantee data
> integrety.
> Obviously, the PostgreSQL developers disagree.
Look: it's an acknowledged bug and it's fixed in current sources.
The disagreement is over whether this single bug is suffic
Justin Clift <[EMAIL PROTECTED]> writes:
> Glad he made the advisory for something there's a fix for. :)
The claim that this bug allows execution of arbitrary code is bogus anyway.
The overflow at INT_MIN will clobber the stack, yes, but in an absolutely
predetermined way; an attacker will have
On Mon, 2002-08-19 at 13:14, Florian Weimer wrote:
> Justin Clift <[EMAIL PROTECTED]> writes:
>
> > You guys *definitely* write scarey code.
>
> Yes, indeed. My code has a lot of unnecessary and error-prone input
> validation checks because I don't trust the PostgreSQL parser.
Bah.. Check the
Justin Clift <[EMAIL PROTECTED]> writes:
> You guys *definitely* write scarey code.
Yes, indeed. My code has a lot of unnecessary and error-prone input
validation checks because I don't trust the PostgreSQL parser.
That's scary. You don't trust your database that it processes a
simple text st
Hi Florian,
You guys *definitely* write scarey code.
:-(
Regards and best wishes,
Justin Clift
Florian Weimer wrote:
>
> Alvar Freude <[EMAIL PROTECTED]> writes:
>
> >> What about checking the input for backslash, quote,
> >> and double quote (\'")? If you are not taking care of those in
Alvar Freude <[EMAIL PROTECTED]> writes:
>> What about checking the input for backslash, quote,
>> and double quote (\'")? If you are not taking care of those in input
>> then crashing the backend is going to be the least of your worries.
>
> with Perl and *using placeholders and bind values
Hi Vince,
Glad he made the advisory for something there's a fix for. :)
Regards and best wishes,
Justin Clift
Vince Vielhaber wrote:
>
> Surprised it took this long.
>
> Vince.
> --
> ==
> Vince Vielhaber -- KA8CSH
Surprised it took this long.
Vince.
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
http://www.camping-usa.com h
> OK, with two people now asking to have the patch removed, and with no
> comment from Thomas, I have removed the patch. This removes XLogDir
> environment variable, and -X postmaster/postgres/initdb/pg_ctl flag.
> I have also removed the code that dynamically sized xlogdir.
... Back in town...
Since there didn't seem to be anyone objecting to the notion of
decoupling UNIQUE from SERIAL, I'm going to go ahead with
reviewing/applying Rod's recent patch that does that (and fixes pg_dump
to dump 7.3 serials correctly). We can continue to debate about
the merits of making additional changes
> Automatically? How will it determine which database(s) contain the
> types? What if the databases require password access?
>
> It probably would be useful to supply an uninstall SQL script to reverse
> the effects of the install script, but since we have no idea where the
> install was run I
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> It would be really neat if the contrib makefile could run an sql script upon
> uninstall as well as removing the files. Is that a neat idea? Means it can
> get rid off all the functions, types, etc. automatically.
Automatically? How will
Hi Guys,
It would be really neat if the contrib makefile could run an sql script upon
uninstall as well as removing the files. Is that a neat idea? Means it can
get rid off all the functions, types, etc. automatically.
Unfortunately it's a bit beyond my meagre Makefile abilities...
Chris
-
On Mon, 2002-08-19 at 09:42, Curt Sampson wrote:
> On Mon, 19 Aug 2002, Zeugswetter Andreas SB SD wrote:
>
> > > So what you're saying is that constraints shouldn't be inherited?
> >
> > No. I even said that inheriting should be the default.
>
> Ah. So you think it should be possible not to inhe
On Mon, 2002-08-19 at 15:42, Curt Sampson wrote:
> > A local constraint should be made obvious from looking at the schema,
>
> Ok, this now I could live with. Though I'm not sure that its
> theoretically very defensible, or worth the effort. Other languages
> that offer constraints, such as Eiffe
On Mon, 19 Aug 2002, Zeugswetter Andreas SB SD wrote:
> > So what you're saying is that constraints shouldn't be inherited?
>
> No. I even said that inheriting should be the default.
Ah. So you think it should be possible not to inherit constraints.
> A local constraint should be made obvious f
Philip Warner <[EMAIL PROTECTED]> writes:
> At 15:41 19/08/2002 +0800, Christopher Kings-Lynne wrote:
>> So it seems Philip already has what he wants?
> I really hope so, but my understanding is that this information is used
> during optimization, not execution; I want it to be used in execution
> > > Yes, that's the whole point. If I have a constraint on a table, I think
> > > it should *never* be possible for that constraint to be violated. If a
> > > subtable should not have constraint the supertable has, it shouldn't
> > > inherit from the supertable.
> >
> > If you want that, you si
Manfred Koizar <[EMAIL PROTECTED]> writes:
> Having contributed to the need for pg_dump/initdb/restore when
> upgrading from 7.2 to 7.3, I plan to submit a patch which *could* make
> future transitions easier.
We do need a page version code but I do not want to waste 4 bytes per
page on it.
I wa
On Mon, 19 Aug 2002, Zeugswetter Andreas SB SD wrote:
> > Yes, that's the whole point. If I have a constraint on a table, I think
> > it should *never* be possible for that constraint to be violated. If a
> > subtable should not have constraint the supertable has, it shouldn't
> > inherit from th
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> The man page says:
>SET variable { TO | = } { value | 'value' | DEFAULT }
> So user naturally thinks
> set search_path to 'public,s1';
> is a correct syntax, no?
The man page needs improvement --- some variables accept a list of
values now. In
Philip Warner <[EMAIL PROTECTED]> writes:
> My theory is that if such a piece of code gets a performance gain, then the
> code is probably worth including, assuming that the function manager does
> not need to be butchered to achieve the desired goal. Does that sound
> reasonable?
Some real re
> > Seems with above you are not able to constrain what qualifies for a
> > supertable row, you would only be able to specify constraints that
> > apply to all it's subtables.
>
> Yes, that's the whole point. If I have a constraint on a table, I think
> it should *never* be possible for that con
Having contributed to the need for pg_dump/initdb/restore when
upgrading from 7.2 to 7.3, I plan to submit a patch which *could* make
future transitions easier.
bufpage.h:
typedef struct PageHeaderData
{
...
uint32 pd_type;/* kind and version */
...
}
#define PK
I'd have thought that if a matching user couldn't be found in the
specified database then it would default to searching through the
global users? Would be more intuitive...
Lee.
Bruce Momjian writes:
> Sample run:
> $ psql -U postgres test
> psql: FATAL: user "postgres@test" does n
At 15:41 19/08/2002 +0800, Christopher Kings-Lynne wrote:
>So it seems Philip already has what he wants?
I really hope so, but my understanding is that this information is used
during optimization, not execution; I want it to be used in execution.
> >What Philip seems to be asking for is a mechanism where by if a function
> >is marked as being mathematically deterministic (given a
> particular set of
> >parameters the same result is always returned -- eg: cos(), sin(),
> >etc) then the result is cached and next time the function is called w
At 17:03 19/08/2002 +1000, Gavin Sherry wrote:
>What Philip seems to be asking for is a mechanism where by if a function
>is marked as being mathematically deterministic (given a particular set of
>parameters the same result is always returned -- eg: cos(), sin(),
>etc) then the result is cached
81 matches
Mail list logo
