[HACKERS] Build failure in current CVS (src/backend/utils/mb/conversion_procs)

2002-08-20 Thread John Gray

Hi all,

I get the following when I attempt to build outside of the source tree.
All goes well until

make[4]: Entering directory
`/home/jgray/postgres/pg-build/src/backend/utils/mb/conversion_procs/ascii_and_mic'
Makefile:11: ../proc.mk: No such file or directory
make[4]: *** No rule to make target `../proc.mk'.  Stop.


Any suggestions. I've tried various things (cf. my previous message to
-hackers but had no success -I really don't quite get all the details of
the build or I would send a patch...)

Regards

John

-- 
John Gray   
Azuli IT
www.azuli.co.uk 



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] [SECURITY] DoS attack on backend possible

2002-08-20 Thread Curt Sampson

On Mon, 19 Aug 2002 [EMAIL PROTECTED] wrote:

 $input = user'name;
 INSERT INTO db (name) VALUES ('$input');

 will fail because the ' in the input needs to be escaped with a
 backslash.

It will fail because you're doing this a very, very, very bad way.
Why rewrite this kind of stuff when the vendor has already made
correct code available?

PreparedStatement stmt = connection.prepareStatement(
INSERT INTO db (name) VALUES (?));
stmt.setString(user'name);
stmt.execute();

cjs
-- 
Curt Sampson  [EMAIL PROTECTED]   +81 90 7737 2974   http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light.  --XTC


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Vince Vielhaber

On Mon, 19 Aug 2002, 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 something about
 subdividing type opaque into multiple pseudo-types with more carefully
 defined meanings.  cash_out is declared cash_out(opaque) which does not
 really mean that it accepts any input type ... but one of the several
 meanings of opaque is accepts any type, so the parser doesn't reject
 cash_out(2).

 I'd like to see something done about this fairly soon, but it's not
 happening for 7.3 ...

Can we trap and just return an error before it goes into the weeds and
put the subdividing opaque fix in later?

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  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==




---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Nigel J. Andrews

On Mon, 19 Aug 2002, 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 something about
 subdividing type opaque into multiple pseudo-types with more carefully
 defined meanings.  cash_out is declared cash_out(opaque) which does not
 really mean that it accepts any input type ... but one of the several
 meanings of opaque is accepts any type, so the parser doesn't reject
 cash_out(2).
 
 I'd like to see something done about this fairly soon, but it's not
 happening for 7.3 ...

Does anyone have an idea about what other functions are affected by this?

As a stop gap measure to remove the *known* DoS issue how about changing the
pg_proc entry to restrict input types, i.e. not cash_out(opaque)? cash_words is
already listed as only taking the money type is cash_out really that different?

On a related topic cash_out() is listed in pg_proc as returning an int4 but
doesn't the code clearly show that is incorrect?


-- 
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] regression test failures in CVS HEAD

2002-08-20 Thread Rod Taylor

Looks like the expected files weren't updated.

Probably my fault, but the tests themselves are fine.

On Tue, 2002-08-20 at 01:37, Neil Conway wrote:
 The 'type_sanity' and 'domain' regression tests seem to fail with CVS
 HEAD. Here's the diff:
 
 *** ./expected/type_sanity.outSun 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 (p1.typlen = 0 AND p1.typlen != -1) OR
 ! (p1.typtype != 'b' AND p1.typtype != 'c' AND p1.typtype != 'p') OR
   NOT p1.typisdefined OR
   (p1.typalign != 'c' AND p1.typalign != 's' AND
p1.typalign != 'i' AND p1.typalign != 'd') OR
 --- 16,22 
   SELECT p1.oid, p1.typname
   FROM pg_type as p1
   WHERE (p1.typlen = 0 AND p1.typlen != -1) OR
 ! p1.typtype not in('b', 'c', 'd', 'p') OR
   NOT p1.typisdefined OR
   (p1.typalign != 'c' AND p1.typalign != 's' AND
p1.typalign != 'i' AND p1.typalign != 'd') OR
 ***
 *** 60,66 
   -- NOTE: as of 7.3, this check finds SET, smgr, and unknown.
   SELECT p1.oid, p1.typname
   FROM pg_type as p1
 ! WHERE p1.typtype = 'b' AND p1.typname NOT LIKE '\\_%' AND NOT EXISTS
   (SELECT 1 FROM pg_type as p2
WHERE p2.typname = ('_' || p1.typname)::name AND
  p2.typelem = p1.oid);
 --- 60,66 
   -- NOTE: as of 7.3, this check finds SET, smgr, and unknown.
   SELECT p1.oid, p1.typname
   FROM pg_type as p1
 ! WHERE p1.typtype in ('b','d') AND p1.typname NOT LIKE '\\_%' AND NOT EXISTS
   (SELECT 1 FROM pg_type as p2
WHERE p2.typname = ('_' || p1.typname)::name AND
  p2.typelem = p1.oid);
 
 ==
 
 *** ./expected/domain.out Fri Jul 12 14:43:19 2002
 --- ./results/domain.out  Tue Aug 20 01:32:57 2002
 ***
 *** 143,154 
   ( col1 ddef1
   , col2 ddef2
   , col3 ddef3
 ! , col4 ddef4
   , col5 ddef1 NOT NULL DEFAULT NULL
   , col6 ddef2 DEFAULT '88'
   , col7 ddef4 DEFAULT 8000
   , col8 ddef5
   );
   insert into defaulttest default values;
   insert into defaulttest default values;
   insert into defaulttest default values;
 --- 143,155 
   ( col1 ddef1
   , col2 ddef2
   , col3 ddef3
 ! , col4 ddef4 PRIMARY KEY
   , col5 ddef1 NOT NULL DEFAULT NULL
   , col6 ddef2 DEFAULT '88'
   , col7 ddef4 DEFAULT 8000
   , col8 ddef5
   );
 + NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index 'defaulttest_pkey' 
for table 'defaulttest'
   insert into defaulttest default values;
   insert into defaulttest default values;
   insert into defaulttest default values;
 
 ==
 
 Cheers,
 
 Neil
 
 -- 
 Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC
 
 
 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster
 



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread D'Arcy J.M. Cain

On August 19, 2002 11:58 pm, Rod Taylor wrote:
 On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
 The simple fix is to drop the money type entirely as it serves few
 purposes -- but there are some who use it.

As the original creator of the type I probably have the most emotional 
attachment to it but even I am thinking of dropping its use.  I would have 
preferred to fix it (more automatic casts and 64 bit storage as well as the 
fixes in the current thread) but I seem to be alone so it hardly seems worth 
it.  I still think that there is some benefit to being able to do integer 
arithmetic though.  I know that I do a lot of calculations (mostly sums) on 
money and going to numeric is going to be a hit.  No matter how efficient it 
is it can't be as efficient as a cpu register addition.

But maybe I'm wrong and the hit will be negligible.

-- 
D'Arcy J.M. Cain darcy@{druid|vex}.net   |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



[HACKERS] bison news

2002-08-20 Thread Michael Meskes

I just got the latest beta and it compiles ecpg grammar correctly! I had
to make one change to my source though as bison no longer accepts a comma inside the 
token list.

Michael

-- 
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] [SECURITY] DoS attack on backend possible

2002-08-20 Thread ngpg

[EMAIL PROTECTED] (Curt Sampson) wrote in
 On Mon, 19 Aug 2002 [EMAIL PROTECTED] wrote:
 
 $input = user'name;
 INSERT INTO db (name) VALUES ('$input');

 will fail because the ' in the input needs to be escaped with a
 backslash.
 
 It will fail because you're doing this a very, very, very bad way.
 Why rewrite this kind of stuff when the vendor has already made
 correct code available?
 
 PreparedStatement stmt = connection.prepareStatement(
  INSERT INTO db (name) VALUES (?));
 stmt.setString(user'name);
 stmt.execute();
 
 cjs

Curt:
I am not doing it this way, I am trying to point out that doing it without 
doing something (whether it be using preparedstatement or WHATEVER), is, 
as you say, very very very bad (I am agreeing with you).  I am further 
saying that whatever it is you do, you should also be doing some other 
simple validation, like the length of the inputs, because most inputs wont 
be over 255 chars before being prepared.  This is just an example, but you 
should do whatever validation would apply to you (and this is probably true 
coding for any user input whether it involves a db or not).  I am just 
saying this is good practice in my opinion and had these people that 
brought up the issue in the first place were doing it, then pgsql's 
shortcomings would not have been as severe a problem.  Things I am not 
saying are:  its ok for pgsql to have this DoS problem;  its the frontends 
responsibility to maintain data integrity not the backend.

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Vince Vielhaber

On Tue, 20 Aug 2002, D'Arcy J.M. Cain wrote:

 On August 19, 2002 11:58 pm, Rod Taylor wrote:
  On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
  The simple fix is to drop the money type entirely as it serves few
  purposes -- but there are some who use it.

 As the original creator of the type I probably have the most emotional
 attachment to it but even I am thinking of dropping its use.  I would have
 preferred to fix it (more automatic casts and 64 bit storage as well as the
 fixes in the current thread) but I seem to be alone so it hardly seems worth
 it.  I still think that there is some benefit to being able to do integer
 arithmetic though.  I know that I do a lot of calculations (mostly sums) on
 money and going to numeric is going to be a hit.  No matter how efficient it
 is it can't be as efficient as a cpu register addition.

 But maybe I'm wrong and the hit will be negligible.

I used to use the money tag but someone said it was going away in a future
version and to use the numeric type instead.  I was under the impression
that it was going to be history long before now - it seems I was told this
back in 6.3.something.

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  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==




---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Bruno Wolff III

On Mon, Aug 19, 2002 at 22:35:26 -0700,
 
 Most computer virus problems are caused by buffer overrun.  Someone
 decided it wasn't very important.

I disaggree with this. Most computer viruses that I see are rely on
poorly designed software and poorly trained users to propagate.

Buffer overruns are used by worms and by some tools designed to get unauthorized
access to machines.

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Jan Wieck

Justin Clift wrote:
 
 Hi Mark,
 
 Mark Pritchard wrote:
 
 [...]
  Finally, question the due dilligence process that selects an ISP partner who
  would leave a database open to the world, even if they run unbreakable
  Oracle :)
 
 This is the one point of yours I don't feel you've quite got down pat.
 Err... *why* is it safe to leave a HTTP, SSH, IMAP, etc server open to
 the world (configured correctly of course), but somehow fundamentally
 wrong to leave a database server open to the world.  If we've got a
 product without these bugs, there wouldnt be a security vulnerability
 would there?

Because in every system I've seen so far, the application plays a major
role in ensuring the data integrity by implementing at least part of the
business logic. Referential integrity and all the stuff is nice to have
and supports the application developer fighting against concurrency
issues, very hard to solve on the application layer. But the decision if
accountant Victor is permitted to cancel this payment for Hugo is still
up to the application.

If you say your users need direct DB access on the SQL interface level,
I say trash your application because the data it produces isn't worth
the magnetism on the media. It's not that we ugently need to fix such a
bug that can only cause a DOS in case someone finds a way to hack
through the application into the SQL interface. It's that the
application has to be fixed not to allow that, because even if the
server wouldn't be crashable, such a hack would end in a disaster. 


Jan

-- 

#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.  #
#== [EMAIL PROTECTED] #

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Tom Lane

Vince Vielhaber [EMAIL PROTECTED] writes:
 On Mon, 19 Aug 2002, Tom Lane wrote:
 I'd like to see something done about this fairly soon, but it's not
 happening for 7.3 ...

 Can we trap and just return an error before it goes into the weeds and
 put the subdividing opaque fix in later?

I don't think there's any quick and dirty solution.

One thing we could probably do in a relatively short amount of time,
considering that we already have one pseudo-type in the system, is to
go ahead and invent the C string pseudo-type and then change all the
built-in I/O functions to be declared as taking or returning C string
(as appropriate).  We couldn't really do strong type checking on this
yet, because we couldn't expect user-defined types' I/O functions to be
declared correctly for awhile yet, but at least it would plug the hole
for built-in types.

What this needs is someone to do the legwork...

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Greg Copeland

On Tue, 2002-08-20 at 00:35, Dann Corbit wrote:
 
 Most computer virus problems are caused by buffer overrun.  Someone
 decided it wasn't very important.

This is true.  IMO, it is extremely arrogant to ignore a buffer overrun
and announce it can't be exploited.  There is many cases where this
assertion has been proved to be false.  The real risk of overrun is not
what you think can be done with it (or lack there of), rather, it's how
someone else might decide to use it in some obscure manner which you can
not currently fathom or foresee.

 Will you trust your multi-million dollar database to someone who says
 the above?  I think the priorities are upside down.  Any *known*
 buffer-overrun _must_ be repaired, and as quickly as possible.  And

I agree with that too.  When setting priorities, using a scale of 1-10,
10 being highest priority, anything that effects stability or
reliability should always be a 10.  As such, they should always be
repaired even above new wiz-bang features.

IMO, if you don't embrace that rule of thumb, a developer shouldn't be
working on a project where stability and reliability are key components
of the end product.

 potential overruns should be identified.  A grep for memcpy, strcpy,
 gets, etc. should hunt down most of them.  A known buffer overrun should
 fill the designer of a product with abject terror.  And I really mean

Agreed.  It is horribly irresponsible to thumb a nose at such things in
this day and age.

 that, literally.  If you *know* of a buffer overrun, and simply decide
 not to fix it, that sounds very negligent to me.  For a public project
 like PostgreSQL, there is probably very little liability for the
 programmers, but I am thinking of the damage that can be inflicted upon
 potential clients using the database.
 

Not a question of it sounding negligent.  It is negligent.

If quality and stability is not the core developers #1 goal then
expecting people to trust the resulting product is laughable.  Please
tell me why anyone should use a database to maintain important data when
quality and stability is not important to the developers of such a
product.  It's an oxymoron.

Time and time again I've read what basically amounts to, ...if someone
can crash it it's because someone is stupid enough to allow someone to
be able to do it in the first place...  Maybe you're right.  After all,
if core developers continue to turn a blind eye to such issues, they are
in fact, the facilitators of allowing people to do it to begin with. 
That is, they are the ones that allowing people to do it in the first
place.  In short, every time I see that response, I immediately think,
...now that's the pot calling the kettle black.

At some point in time, you have to stand and say, the buck stops here.

Now then, after that long rant and rave, since these are known issues, I
don't have a problem with the next release going out as planned.  Once
it does go out, I would certainly hope that the developers would
readjust their priorities and target a bug fix release to immediately
follow.

You know, I've seen many people trash Oracle's unbreakable mantra. 
I'm sure no one is confused at the fact that it is nothing but a
marketing ploy, however, perhaps there is a culture behind it.  Perhaps
this is their way of saying stability and reliability is very important
to them.  Perhaps their mantra is the rule of thumb outlined above.

Sign,

Greg Copeland






signature.asc
Description: This is a digitally signed message part


Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Jan Wieck

Dann Corbit wrote:
 [...]
 
 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 problems?

And what others tried to tell you is, that there are different types of
systems and levels of vulnerability. A software that by nature needs to
be exposed to the internet (like an SMTP, HTTP or SSH server) is in high
danger and needs to be fixed immediately. But software that by nature
needs to be well protected from uncontrolled access (like a database, a
backup management system or a logical volume manager) does not.

The matter of the fact is, that if you grant someone access to your
database that gives him the power to execute the statement that triggers
this bug, you're lost anyway. Whatever constraints you have set up, an
empty database is usually very consistent but not neccessarily useful.


Jan

-- 

#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.  #
#== [EMAIL PROTECTED] #

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Greg Copeland

On Tue, 2002-08-20 at 08:05, Jan Wieck wrote:
 If you say your users need direct DB access on the SQL interface level,
 I say trash your application because the data it produces isn't worth
 the magnetism on the media. It's not that we ugently need to fix such a
 bug that can only cause a DOS in case someone finds a way to hack
 through the application into the SQL interface. It's that the
 application has to be fixed not to allow that, because even if the
 server wouldn't be crashable, such a hack would end in a disaster. 
 

The problem is, the vast majority of these issues are actually caused by
internal resources (people) rather than external attacks.

The real fear is internal resources DoSing internal resources.  The
reaction on the list is usually to look outward for sources of possible
problems.  That in it self is a problem.  It's well documented the vast
majority (what, 70+%) of these issues actually originate internally.

It is because of these issues that it is often, no longer an issue of
application this or that, as an application may of been completely
bypassed.

And yes, you can argue all day long that if this happens, you should be
fearing destruction of your data.  While that's true, data can be
restored.  It also requires a different personality type.  Many people
would be willing to DoS a system, however, that doesn't have to mean
they are willing to destroy data.


Regards,

Greg Copeland





signature.asc
Description: This is a digitally signed message part


Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Tom Lane

Nigel J. Andrews [EMAIL PROTECTED] writes:
 I'd like to see something done about this fairly soon, but it's not
 happening for 7.3 ...

 Does anyone have an idea about what other functions are affected by this?

As a first approximation, every output function for a built-in
pass-by-reference datatype will show this same behavior.  cash_out is
just getting picked on because it was the one mentioned in the first
complaint.  For that matter, every input function for any datatype
has the same problem:
regression=# select cash_in(2);
server closed the connection unexpectedly

Let's see ... I count 264 standard pg_proc entries that are declared
with one or more opaque parameters.  Many but by no means all are I/O
functions.  There are another 13 standard functions declared to return
opaque.  To plug the hole in a credible fashion we'd need to do
something about every one of these; so belay that last suggestion that
just implementing a C string pseudo-type would be enough to be
meaningful.

Right offhand it looks like we'd need at least:
C string for the I/O functions
internal type for index access functions, selectivity, etc
any array for array_eq and array_dims
any type for count(*) (and not much else!)
tuple for the return type of trigger functions
void for the return type of things that return void
not sure about encoding conversion functions

The functions handling internal-type stuff are probably things we don't
want the user calling at all.  As long as we don't declare any of them
to *return* an internal type, there would be no way to construct a
function call that the parser would accept, so that hole would be
plugged with just one pseudo-type; we don't really need to distinguish
which internal type is meant in any one case.  The any array
pseudo-type would probably take a special-case kluge in parse_coerce,
but that doesn't seem intolerable.

Anyone see something I missed?  Tatsuo, what exactly should the function
signature really be for all those encoding conversion functions you just
added?

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Rod Taylor

On Tue, 2002-08-20 at 08:22, D'Arcy J.M. Cain wrote:
 On August 19, 2002 11:58 pm, Rod Taylor wrote:
  On Mon, 2002-08-19 at 23:50, Christopher Kings-Lynne wrote:
  The simple fix is to drop the money type entirely as it serves few
  purposes -- but there are some who use it.
 
 As the original creator of the type I probably have the most emotional 
 attachment to it but even I am thinking of dropping its use.  I would have 
 preferred to fix it (more automatic casts and 64 bit storage as well as the 

 But maybe I'm wrong and the hit will be negligible.

It wouldn't fix this particular problem anyway :) -- so I'm going to
vote to keep it.

Though for my own work I've created a money domain due to lack of digits
with the type -- not to mention I needed to store hundredths of a cent.


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] bison news

2002-08-20 Thread Michael Meskes

On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote:
 BTW, I spent some time looking at the problem, and it seems the issue
 is not overrun of any bison internal table, but failure to compress the
 resulting action table into 32K entries.  This means that the required

Ouch! This of course is not so much a problem for ecpg but for the
backend should we run into the problem there too.

 ...
 Also, it seemed to me that the most leverage on the size of the
 compressed action table would be gained by reducing the number of
 terminal symbols, more so than the number of rules.  Dunno if there
 is a lot you can do about that, but it's a thought.

Will look at it.

Michael
-- 
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] bison news

2002-08-20 Thread Tom Lane

Michael Meskes [EMAIL PROTECTED] writes:
 On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote:
 BTW, I spent some time looking at the problem, and it seems the issue
 is not overrun of any bison internal table, but failure to compress the
 resulting action table into 32K entries.  This means that the required

 Ouch! This of course is not so much a problem for ecpg but for the
 backend should we run into the problem there too.

As of CVS tip a few days ago, the backend's action table was about 27K
entries.  So we have some breathing room, but certainly in the
foreseeable future there will be a problem...

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] [SECURITY] DoS attack on backend possible

2002-08-20 Thread Zeugswetter Andreas SB SD


  with Perl and *using placeholders and bind values*, the application
  developer has not to worry about this. So, usually I don't check the
  values in my applications (e.g. if only values between 1 and 5 are
  allowed and under normal circumstances only these are possible), it's the
  task of the database (check constraint). 
 
 That's the idea.  It's the job of the database to guarantee data
 integrety.

Yes, but what is currently missing is a protocol to the backend
where a statement is prepared with placeholders and then executed
(multiple times) with given values. Then there is no doubt what is a
value, and what a part of the SQL.

I think that this would be a wanted feature of the next
protocol version. iirc the backend side part is currently beeing 
implemented.

Andreas

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Tom Lane

Tatsuo Ishii [EMAIL PROTECTED] writes:
 Anyone see something I missed?  Tatsuo, what exactly should the function
 signature really be for all those encoding conversion functions you just
 added?

 test=# \df iso8859_1_to_utf8
   List of functions
  Result data type |   Schema   |   Name|   Argument data types   
 --++---+-
  integer  | pg_catalog | iso8859_1_to_utf8 | integer, integer, -, -, integer

Right, that's what they are now, but what do the - entries really
mean?  Also, are the integer args and result truthful, or do they
really mean something else?

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Nigel J. Andrews

On Tue, 20 Aug 2002, Tom Lane wrote:

 Nigel J. Andrews [EMAIL PROTECTED] writes:
  I'd like to see something done about this fairly soon, but it's not
  happening for 7.3 ...
 
  Does anyone have an idea about what other functions are affected by this?
 
 As a first approximation, every output function for a built-in
 pass-by-reference datatype will show this same behavior.  cash_out is
 just getting picked on because it was the one mentioned in the first
 complaint.  For that matter, every input function for any datatype
 has the same problem:
   regression=# select cash_in(2);
   server closed the connection unexpectedly

 ...

But going back to the idea that it seems that the only problem being publicised
in the 'outside world' is the cash_out(2) version can we not do the restriction
on acceptable input type in order to claim that the fix?

Obviously this is only a marketing ploy but on the basis that a real fix seems
unlikely before beta in 11 days time (I'm still trying to work out what Tom's
suggestion is) perhaps one worth implementing.
 

-- 
Nigel J. Andrews
Director

---
Logictree Systems Limited
Computer Consultants


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Tom Lane

Nigel J. Andrews [EMAIL PROTECTED] writes:
 But going back to the idea that it seems that the only problem being
 publicised in the 'outside world' is the cash_out(2) version can we
 not do the restriction on acceptable input type in order to claim that
 the fix?

Totally pointless IMHO, when the same problem exists in hundreds of
other functions.  Also, there really is no way to patch cash_out per se;
the problem is a system-level problem, namely failure to enforce type
checking.  cash_out has no way to know that what it's been passed is the
wrong kind of datum.

Basically, we've used opaque as a substitute for accurate type
declarations; that's got to stop.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow

2002-08-20 Thread Joe Conway

Tom Lane wrote:
 Nigel J. Andrews [EMAIL PROTECTED] writes:
 
I'd like to see something done about this fairly soon, but it's not
happening for 7.3 ...

 
Does anyone have an idea about what other functions are affected by this?
 
 
 As a first approximation, every output function for a built-in
 pass-by-reference datatype will show this same behavior.  cash_out is
 just getting picked on because it was the one mentioned in the first
 complaint.  For that matter, every input function for any datatype
 has the same problem:
   regression=# select cash_in(2);
   server closed the connection unexpectedly
 
 Let's see ... I count 264 standard pg_proc entries that are declared
 with one or more opaque parameters.  Many but by no means all are I/O
 functions.  There are another 13 standard functions declared to return
 opaque.  To plug the hole in a credible fashion we'd need to do
 something about every one of these; so belay that last suggestion that
 just implementing a C string pseudo-type would be enough to be
 meaningful.

Is there ever a reason for a user to call a function with an opaque 
parameter directly? If not, can we simply REVOKE EXECUTE for these 
functions?


Joe


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Ross J. Reedstrom

On Tue, Aug 20, 2002 at 11:28:32AM -0400, Tom Lane wrote:
 Nigel J. Andrews [EMAIL PROTECTED] writes:
  But going back to the idea that it seems that the only problem being
  publicised in the 'outside world' is the cash_out(2) version can we
  not do the restriction on acceptable input type in order to claim that
  the fix?
 
 Totally pointless IMHO, when the same problem exists in hundreds of
 other functions.  Also, there really is no way to patch cash_out per se;
 the problem is a system-level problem, namely failure to enforce type
 checking.  cash_out has no way to know that what it's been passed is the
 wrong kind of datum.
 
 Basically, we've used opaque as a substitute for accurate type
 declarations; that's got to stop.

Hmm, are there _any_ cases where it's appropriate to call an 'opaque'
function directly from user code? cash_out() and it's kin are type
output functions that are called under controlled conditions, with
backend controlled parameters. Trigger functions also are called with
backend controlled parameters. Is there a 'hack' fix that doesn't allow
opaque returning functions in user-defined locations?

Ross

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Lamar Owen

On Tuesday 20 August 2002 11:28 am, Tom Lane wrote:
 Nigel J. Andrews [EMAIL PROTECTED] writes:
  But going back to the idea that it seems that the only problem being
  publicised in the 'outside world' is the cash_out(2) version can we
  not do the restriction on acceptable input type in order to claim that
  the fix?

 Basically, we've used opaque as a substitute for accurate type
 declarations; that's got to stop.

Umm, but what about the reply buffer overrun advisory?  I've read this whole 
thread, and the reply advisory (AFAICT, unless I've just hit delete too 
quickly) has NOT been addressed.  Let's repeat the salient portion of Florian 
Weimer's message:

 PostgreSQL 7.2.1 has a buffer overflow bug in the date parser (which
 is invoked each time a string is converted to a datetime object).  If
 a frontend does not perform proper date checking and rejects overlong
 date strings, a buffer is overwritten by parser.  The string has to
 pass some checks of the parser, so it is not immediately obvious that
 this can be exploited.  Denial of service is possible, though,
 especially if the frontend does not automatically reestablish the
 database connection. (All connections are affected, not just the one
 that is issueing the query.)

In the DATE parser, not money.  Not cash_out.  Where do we stand on the DATE 
overrun, if one actually exists?  If it exists, can it be exploited by a bad 
date entry on someone's web form or other client application? If it's not 
exploitable, then it lessens the impact -- but it is irresponsible to assume 
that just because we can't find a way to exploit it that no one else can.

Now it's possible I just hit delete too quickly; but it's also possible that 
everyone has just assumed that this was the cash_out problem and has started 
hashing on that.  Although this reply advisory hasn't been out as long as the 
original one, which WAS cash_words.

If there is indeed an exploitable overrun in the DATE parser, then I believe 
we should issue a 7.2.2 to fix this problem.  I know that MANY people will be 
using 7.2.x for quite awhile, as they won't want to make a MAJOR database 
upgrade (which is not painless thanks to the need to use 7.3's pg_dump for 
things).  If the upgrade was painless, I'd agree that 7.3 is the solution -- 
but a real security fix shouldn't wait for 7.3.  But I'm holding judgment on 
a proven exploit.  A proven exploit will change my mind to say 'we need a 
7.2.2 NOW that fixes this overrun.'
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Tom Lane

Lamar Owen [EMAIL PROTECTED] writes:
 Umm, but what about the reply buffer overrun advisory?  I've read this whole 
 thread, and the reply advisory (AFAICT, unless I've just hit delete too 
 quickly) has NOT been addressed.

Yes it has.  CVS logs show

2002-08-04 02:44  thomas

* src/backend/utils/adt/: date.c, datetime.c, format_type.c,
nabstime.c, timestamp.c, varlena.c: Add guard code to protect from
buffer overruns on long date/time input  strings. [other
comments pruned, but note this commit did a lot of other stuff too]

The original argument was about whether we should push out a 7.2.2
release just because of this fix.  AFAIK no one has even troubled to
look at the patch and see whether it applies directly to the 7.2 branch;
Thomas has revised the date/time code quite a bit since 7.2, so I'd
expect that it's not going to apply exactly.

I'd put more stock in the concern level of the people making complaints
if anyone had bothered to do even that much legwork.  Without an offered
patch against 7.2 branch, I don't think the folks who push out releases
(which is not me, but Marc, Bruce, you, Trond, etc) should bother to
take notice of the complaints at all.

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Lamar Owen

On Tuesday 20 August 2002 12:15 pm, Tom Lane wrote:
 Lamar Owen [EMAIL PROTECTED] writes:
  Umm, but what about the reply buffer overrun advisory?  I've read this
  whole thread, and the reply advisory (AFAICT, unless I've just hit delete
  too quickly) has NOT been addressed.

 Yes it has.  CVS logs show

 I'd put more stock in the concern level of the people making complaints
 if anyone had bothered to do even that much legwork.  Without an offered
 patch against 7.2 branch, I don't think the folks who push out releases
 (which is not me, but Marc, Bruce, you, Trond, etc) should bother to
 take notice of the complaints at all.

If a patch is proffered to 7.2.1 to fix this, I'll be happy to roll a new 
RPMset.  I tend to agree with you on this detail, Tom.

I had just apparently missed that portion; thanks for the reminder.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] [SECURITY] DoS attack on backend possible

2002-08-20 Thread Florian Weimer

Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:

 Yes, but what is currently missing is a protocol to the backend
 where a statement is prepared with placeholders and then executed
 (multiple times) with given values. Then there is no doubt what is a
 value, and what a part of the SQL.

This wouldn't have helped in the current case.  The bug is in the
datetime parser which translates strings to an external
representation, not in the SQL parser.

-- 
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart   http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT  fax +49-711-685-5898

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] Build failure in current CVS (src/backend/utils/mb/conversion_procs)

2002-08-20 Thread Tom Lane

John Gray [EMAIL PROTECTED] writes:
 I get the following when I attempt to build outside of the source tree.

It looks like the new stuff for loadable conversion modules is not
correct for building outside the source tree; it's being careless about
the paths it uses to find files.  Tatsuo, can you fix that, or ask Peter
for help?

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



[HACKERS] Proposal: make opaque obsolete

2002-08-20 Thread Tom Lane

Okay, I'm tired of hearing about this, and I've decided I can make the problem
go away with a day or so's concentrated work.

Here is the plan:

Create several pseudo types (typtype 'p' in pg_type).  We already have one
pseudo-type (RECORD), plus the logic in heap.c to reject any attempt to create
a table column that's of a pseudo-type.  I think we need the following
pseudotypes:

cstring -- represents a null-terminated C string
anytype -- for count(*), nullvalue, nonnullvalue *ONLY*
anyarraytype-- for array_eq, array_dims
void-- result type for functions with no useful result
tuple   -- result type for BEFORE triggers
internal-- catchall for non-SQL internal data structures

I am not by any means wedded to the above type names; does anyone have
suggestions for better names?  (In particular, I am wondering if tuple
and internal would be better named pg_tuple and pg_internal.  We
might also consider making a type specifically named trigger and using
that to declare trigger functions, rather than tuple.)

I am also thinking of creating a pseudotype for opaque itself, so that
we can get rid of the kluge of using type OID 0 in places where a valid type
is expected.  We cannot remove opaque completely (yet) because of backwards
compatibility with existing user I/O functions and triggers; but we can see
to it that no built-in or contrib function is declared with opaque.

About I/O behavior: the pg_type entries for these pseudo-types will have to
have typinput and typoutput functions.  In general these I/O routines must
just throw errors.  Otherwise you could break the intended type safety by
supplying user-written constants.  For instance, the present definition of
RECORD is wrong (sorry Joe) because it uses oidin and oidout; so I could
write SELECT foo('42'::record) and thereby crash a function expecting
RECORD.  Not that there will be any such function, but the analogous case
with, say, INTERNAL would be bad news.

An exception is that void_out should succeed and just return an empty string;
this allows functions-returning-void to be called by SELECT and behave
reasonably.  Less obviously, void_in should succeed (and return nothing
interesting, probably just a zero datum; it can ignore its input).  This
allows plpgsql functions to be defined to return VOID.

I am also considering allowing cstring_out to succeed (and, of course,
just return a copy of what it's given).  That would allow explicit invocation
of an output function to work, viz SELECT cash_out('42'::money) would
actually do what the user expects.  This is not really necessary though.
We can't allow cstring_in to succeed, although that looks like a no-brainer,
because the system isn't ready to support CSTRING Datums in general contexts.

Trigger functions will now be expected to take no arguments and return
either tuple (or trigger if we call it that) or opaque.  It would also be
sensible to allow VOID in the case of AFTER triggers, but I'm inclined not
to do so: I think it's better that a trigger function be declared in a way
that makes it clear it's supposed to be a trigger.  If CREATE TRIGGER accepts
functions returning void then I think you lose some useful error checking.

Should we throw a NOTICE stating that opaque is deprecated if a trigger
is declared with opaque?  Or should we wait a release or two for that?

Similarly, the preferred signature for I/O functions now uses cstring
and the function's actual datatype, rather than OPAQUE (and again we
could consider throwing a NOTICE).

One of the original concerns about this was how to handle the circularity
problem for user-defined I/O functions.  If we don't do anything special,
then it will still work as long as people define the input function first:
create function foo_in(cstring) returns foo as ' ... ';
-- you'll get a NOTICE here about type foo is not yet defined
create function foo_out(foo) returns cstring as '...';
-- you'll get another NOTICE here about foo is only a shell
create type foo (input = foo_in, output = foo_out, ...);
Are the notices annoying enough to be a problem?  Is there a way around
them?

Currently, most of the PL languages explicitly check for type opaque as a
function argument or result type, and reject it.  This should be generalized
to reject any pseudo-type except those explicitly supported (which will
probably be nothing except VOID).

Comments?

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] Proposal: make opaque obsolete

2002-08-20 Thread Rod Taylor

   anyarraytype-- for array_eq, array_dims

Will this allow generic array iterator functions in the future?


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] Proposal: make opaque obsolete

2002-08-20 Thread Tom Lane

Rod Taylor [EMAIL PROTECTED] writes:
 anyarraytype -- for array_eq, array_dims

 Will this allow generic array iterator functions in the future?

Hm.  Not directly; there's still the issue of how to tell what element
type the array is.  array_dims doesn't care, and I think that we have
some kluge for array_eq, but in general it'd be a problem for generic
functions.

I had been thinking that as long as we are going to break datafile
compatibility (due to Manfred's tuple-header changes) this would be
a good time to try to clean up the representation of arrays.  It's
bothered me for a long while that the array code is not doing alignment
correctly --- it seems not to matter for any standard type, but arrays
of, say, interval are not aligned the way pg_type says they should be.

The reason I bring this up is that if we are changing the internal
representation of arrays, we could add type OID and perhaps typmod to
the array header, thus making an array value interpretable without any
outside info.  Then you could actually do something interesting with
a function taking anyarraytype.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Zeugswetter Andreas SB SD


 The cash_out problem can't really be fixed until we do something about
 subdividing type opaque into multiple pseudo-types with more carefully
 defined meanings.  cash_out is declared cash_out(opaque) which does not
 really mean that it accepts any input type ... but one of the several
 meanings of opaque is accepts any type, so the parser 
 doesn't reject cash_out(2).

Would it be possible to update the system tables, so that cash_out does not take
opaque but really takes type money ?
I mean the first thing cash_out does is PG_GETARG_CASH(0), so it really only copes 
with a money type.

I know the problem is that the cat chases its tail here, because of what comes first,
the type or the io functions. But couldn't this be overcome, at least for internal 
types ?

Andreas

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] CREATE CAST WITHOUT FUNCTION should require superuserness?

2002-08-20 Thread Peter Eisentraut

Tom Lane writes:

 I think it might be a good idea to require superuser permissions to
 create a binary-equivalence cast.

OK

 Also, in the present state of the code a WITHOUT FUNCTION cast does
 not work if AS ASSIGNMENT isn't given: parse_coerce.c won't ever find
 it.  Is this intentional, or just an oversight?

It's a transition state that might be inadequately documented.  In the
near future the code should be restructured to allow for non-implicit
binary compatible casts.  But currently there are not candidates for that
anyway.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] Proposal: make opaque obsolete

2002-08-20 Thread Stephan Szabo

On Tue, 20 Aug 2002, Tom Lane wrote:

In general I think it sounds good, so I'm only responding to places where
I want to say something specific.

 I am not by any means wedded to the above type names; does anyone have
 suggestions for better names?  (In particular, I am wondering if tuple
 and internal would be better named pg_tuple and pg_internal.  We
 might also consider making a type specifically named trigger and using
 that to declare trigger functions, rather than tuple.)

I like something with trigger better, makes it very obvious that it's a
trigger function.

 An exception is that void_out should succeed and just return an empty string;
 this allows functions-returning-void to be called by SELECT and behave
 reasonably.  Less obviously, void_in should succeed (and return nothing
 interesting, probably just a zero datum; it can ignore its input).  This
 allows plpgsql functions to be defined to return VOID.

Does this require additional work to the plpgsql grammar? The
natural way to return from such a function (return;) doesn't seem like
it'd work without some changes. In any case I don't think this would
be necessary for 7.3.

 I am also considering allowing cstring_out to succeed (and, of course,
 just return a copy of what it's given).  That would allow explicit invocation
 of an output function to work, viz SELECT cash_out('42'::money) would
 actually do what the user expects.  This is not really necessary though.

I like the idea of cstring_out working, but I wonder if we should stop
users from calling the I/O functions directly anyway even if they were
made to be safe.

 Should we throw a NOTICE stating that opaque is deprecated if a trigger
 is declared with opaque?  Or should we wait a release or two for that?
 Similarly, the preferred signature for I/O functions now uses cstring
 and the function's actual datatype, rather than OPAQUE (and again we
 could consider throwing a NOTICE).

I think we should throw the notices right away, although this makes me
wonder in general about upgrade path.  Are we ever planning to make that
an error, and if so, how are we going to handle functions that are coming
from previous versions where it was okay? It's relatively easy to do fix
ones that are currently used as trigger functions or type i/o functions,
but what about ones that aren't being used at dump time?  Do we even need
to do anything?

 One of the original concerns about this was how to handle the circularity
 problem for user-defined I/O functions.  If we don't do anything special,
 then it will still work as long as people define the input function first:
   create function foo_in(cstring) returns foo as ' ... ';
   -- you'll get a NOTICE here about type foo is not yet defined
   create function foo_out(foo) returns cstring as '...';
   -- you'll get another NOTICE here about foo is only a shell
   create type foo (input = foo_in, output = foo_out, ...);
 Are the notices annoying enough to be a problem?  Is there a way around
 them?

I personally don't think it's a big deal, although I'm alot less annoyed
by notices than alot of people.



---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] Proposal: make opaque obsolete

2002-08-20 Thread Tom Lane

Stephan Szabo [EMAIL PROTECTED] writes:
 On Tue, 20 Aug 2002, Tom Lane wrote:
 Less obviously, void_in should succeed (and return nothing
 interesting, probably just a zero datum; it can ignore its input).  This
 allows plpgsql functions to be defined to return VOID.

 Does this require additional work to the plpgsql grammar?

I suspect you'd need to say return 0 (or return anything-at-all,
pretty much) to make it fly with the current plpgsql sources.  This
is a tad ugly but I think we can live with it until someone wants to
fix it.  If we have type void then for sure people will want to use
it for plpgsql functions; there are plenty of cases where you run a
plpgsql function just for side-effects.

 I think we should throw the notices right away, although this makes me
 wonder in general about upgrade path.  Are we ever planning to make that
 an error, and if so, how are we going to handle functions that are coming
 from previous versions where it was okay?

We can't make it an error until sufficiently far down the road that we
don't care about forward compatibility from 7.2-or-before dump files.
That'll be a long while, probably.

Throwing a notice right away is okay with me personally, but I wanted to
see what other people thought...

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



[HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL(fwd)

2002-08-20 Thread Vince Vielhaber


Here's yet another.  He claims malicious code can be run on the server
with this one.

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  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==



-- Forwarded message --
Date: Tue, 20 Aug 2002 14:28:49 +
From: Sir Mordred The Traitor [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL

//@(#)Mordred Labs advisory 0x0003

Release data: 20/08/02
Name: Buffer overflow in PostgreSQL
Versions affected: all versions
Risk: high

--[ Description:

...PostgreSQL is a sophisticated Object-Relational DBMS,
supporting almost all SQL constructs, including subselects,
transactions, and user-defined types and functions. It is the
most advanced open-source database available anywhere...blah...blah...
For more info check out this link:
http://www.postgresql.org/idocs/index.php?preface.html#INTRO-WHATIS

There exists a heap buffer overflow in a repeat(text, integer) function,
which
allows an attacker to execute malicious code.

--[ Details:

Upon invoking a repeat() function, a
src/backend/utils/adt/oracle_compat.c::repeat() function
will gets called which suffers from a buffer overflow.

--[ How to reproduce:

psql select repeat('xxx',1431655765);
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

--[ Solution

Do you still running postgresql? ...Can't believe that...
If so, execute the following command as a root: killall -9 postmaster,
and wait until the patch will be available.




This letter has been delivered unencrypted. We'd like to remind you that
the full protection of e-mail correspondence is provided by S-mail
encryption mechanisms if only both, Sender and Recipient use S-mail.
Register at S-mail.com: http://www.s-mail.com/inf/en


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

2002-08-20 Thread Tom Lane

Vince Vielhaber [EMAIL PROTECTED] writes:
 Here's yet another.  He claims malicious code can be run on the server
 with this one.

regression=# select repeat('xxx',1431655765);
server closed the connection unexpectedly

This is probably caused by integer overflow in calculating the size of
the repeat's result buffer.  It'd take some considerable doing to create
an arbitrary-code exploit, but perhaps could be done.  Anyone want to
investigate a patch?  I think we likely need something like

bufsize = input_length * repeats;
+   /* check for overflow in multiplication */
+   if (bufsize / repeats != input_length)
+   elog(ERROR, repeat result too long);

but I haven't thought it through in detail.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in

2002-08-20 Thread Vince Vielhaber

On Tue, 20 Aug 2002, Tom Lane wrote:

 Vince Vielhaber [EMAIL PROTECTED] writes:
  Here's yet another.  He claims malicious code can be run on the server
  with this one.

 regression=# select repeat('xxx',1431655765);
 server closed the connection unexpectedly

 This is probably caused by integer overflow in calculating the size of
 the repeat's result buffer.  It'd take some considerable doing to create
 an arbitrary-code exploit, but perhaps could be done.  Anyone want to
 investigate a patch?  I think we likely need something like

   bufsize = input_length * repeats;
 + /* check for overflow in multiplication */
 + if (bufsize / repeats != input_length)
 + elog(ERROR, repeat result too long);

 but I haven't thought it through in detail.

Where do we check that this:

result = (text *) palloc(tlen);

is even successful?  Is it in one of the macros (VARATT_SIZEP or VARDATA)?
It appears like it goes into the count and copy regardless.

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  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==




---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

2002-08-20 Thread Tom Lane

Vince Vielhaber [EMAIL PROTECTED] writes:
 Where do we check that this:
   result = (text *) palloc(tlen);
 is even successful?

palloc elogs if it can't allocate the space; it's unlike malloc in that
respect.  I believe it also has a guard to reject requests  1Gb, so
I think it's reasonably proof against internal arithmetic overflows.

This problem is strictly repeat's error, not palloc's.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



[HACKERS] SRA purchases TurboLinux

2002-08-20 Thread Bruce Momjian

SRA/Japan, my employer and a big PostgreSQL support company in Japan,
has announced they have purchased TurboLinux:

http://www.turbolinux.com/news/pr/020820.html

Here is a summary from someone on Slashdot:

* Turbolinux Inc. sold Turbolinux Japan K.K. (its Japanese
subsidary) to SRA. (This is the $1 mil. transaction according to
Slashdot Japan [slashdot.jp] (in Japanese))

* Turbolinux Japan K.K. will become the new Turbolinux Inc.

* Turbolinux Inc. also sold all its Linux distribution business,
logo, trademarks to SRA, but the price is not yet disclosed.

* SRA is also planning to buy the Chinese and Korean joint ventures
between Turbolinux Inc. and local companies.

* The old Turbolinux Inc. will change its name to CenterRex and
focus on software it developed like PowerCockpit or EnFusion.

Not sure how this effects PostgreSQL usage, but it certainly could.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



[HACKERS] Large file support available

2002-08-20 Thread Peter Eisentraut

Large file support is now compiled by default if available.  (Use
--disable-largefile to turn it off.  That's what Autoconf gives us.)

But:

The zlib library uses unsigned ints and unsigned longs for file positions
and offsets.  Depending on how that is used in detail and depending on how
zlib itself is compiled, this may or may not work.

The tar file format (POSIX and traditional) has an inherent limitation on
the size of the member files of 2^33 bytes (pg_dump currently only handles
2^30).  The result in that case continues to be a broken archive.  The GNU
tar format has an extension that would handle 2^89 bytes.  This may be
something interesting to work on.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

2002-08-20 Thread Neil Conway

Tom Lane [EMAIL PROTECTED] writes:

 Vince Vielhaber [EMAIL PROTECTED] writes:
  Here's yet another.  He claims malicious code can be run on the server
  with this one.
 
 regression=# select repeat('xxx',1431655765);
 server closed the connection unexpectedly
 
 This is probably caused by integer overflow in calculating the size of
 the repeat's result buffer.  It'd take some considerable doing to create
 an arbitrary-code exploit, but perhaps could be done.  Anyone want to
 investigate a patch?

This seems to fix the problem:

nconway=# select repeat('xxx',1431655765);
ERROR:  Requested buffer is too large.

It uses the logic you suggested. Just a quick and dirty fix, I may
have missed something... The patch applies cleanly to both CVS HEAD
and the 7.2 stable branch.

Cheers,

Neil

-- 
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC


Index: src/backend/utils/adt/oracle_compat.c
===
RCS file: /var/lib/cvs/pgsql-server/src/backend/utils/adt/oracle_compat.c,v
retrieving revision 1.38
diff -c -r1.38 oracle_compat.c
*** src/backend/utils/adt/oracle_compat.c	20 Jun 2002 20:51:45 -	1.38
--- src/backend/utils/adt/oracle_compat.c	20 Aug 2002 20:27:21 -
***
*** 997,1002 
--- 997,1006 
  	slen = (VARSIZE(string) - VARHDRSZ);
  	tlen = (VARHDRSZ + (count * slen));
  
+ 	/* Check for integer overflow */
+ 	if (tlen / slen != count)
+ 		elog(ERROR, Requested buffer is too large.);
+ 
  	result = (text *) palloc(tlen);
  
  	VARATT_SIZEP(result) = tlen;



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

2002-08-20 Thread Tom Lane

Neil Conway [EMAIL PROTECTED] writes:
 + /* Check for integer overflow */
 + if (tlen / slen != count)
 + elog(ERROR, Requested buffer is too large.);

What about slen == 0?

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

2002-08-20 Thread Neil Conway

Vince Vielhaber [EMAIL PROTECTED] writes:
 Here's yet another.

Should someone from the core team perhaps get in contact with this guy
and ask if he could get in contact with the development team before
publicizing any further security holes? AFAIK that is standard
operating procedure in most cases...

Second, it might be worth pushing a 7.2.2 release containing the fix
for this bug, as well as the datetime problem. If that sounds
reasonable to the people who have to do the most work on a new release
(e.g. Marc), I can volunteer to backport a fix for the datetime
problem.

Cheers,

Neil

-- 
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



[HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows inPostgreSQL. (fwd)

2002-08-20 Thread Vince Vielhaber


And another one.  Sure would be nice if shit-for-brains would mention
it to us first.

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  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==



-- Forwarded message --
Date: Tue, 20 Aug 2002 15:01:34 +
From: Sir Mordred The Traitor [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in
PostgreSQL.


//@(#) Mordred Labs advisory 0x0004

Release data: 20/08/02
Name: Two buffer overflows in PostgreSQL
Versions affected: all versions
Conditions: multibyte support
Risk: average

--[ Description:

I guess all of you already hear about the PostgreSQL.
If not, try to visit
http://www.postgresql.org/idocs/index.php?preface.html#INTRO-WHATIS.

There are two buffer overflows in src/backend/utils/adt/oracle_compat.c.
1) lpad(text, integer, text) function
2) rpad(text, integer, text) function

--[ Details:

The code for this functions is
src/backend/utils/adt/oracle_compat.c::lpad() and
src/backend/utils/adt/oracle_compat.c::rpad() respectively.
The code suffers from a buffer overflow (of course).

--[ How to reproduce:

shell pgsql template1 postgres
template1=# select version();
  version
---
 PostgreSQL 7.2 on i686-pc-linux-gnu, compiled by GCC 2.96
(1 row)

template1=# create database my_db with encoding='UNICODE';
CREATE DATABASE
template1# \c my_db
You are now connected to database my_db.

my_db=# select lpad('x',1431655765,'');
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!#

The same for rpad() function.

The vulnerable encodings are: EUC_JP, EUC_CN, EUC_KR, EUC_TW, UNICODE,
MULE_INTERNAL.

--[ Solution

Secure coding of web applications, input validation checks...etc...




This letter has been delivered unencrypted. We'd like to remind you that
the full protection of e-mail correspondence is provided by S-mail
encryption mechanisms if only both, Sender and Recipient use S-mail.
Register at S-mail.com: http://www.s-mail.com/inf/en


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

2002-08-20 Thread Dann Corbit

 -Original Message-
 From: Neil Conway [mailto:[EMAIL PROTECTED]] 
 Sent: Tuesday, August 20, 2002 1:44 PM
 To: Vince Vielhaber
 Cc: [EMAIL PROTECTED]
 Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: 
 Buffer overflow in PostgreSQL (fwd)
 
 
 Vince Vielhaber [EMAIL PROTECTED] writes:
  Here's yet another.
 
 Should someone from the core team perhaps get in contact with 
 this guy and ask if he could get in contact with the 
 development team before publicizing any further security 
 holes? AFAIK that is standard operating procedure in most cases...

As long as we continue to find out about them, I would just let him work
away.
He is clearly an excellent tester, and if you had to hire him it would
be very expensive.

As long as he is producing results of such great value, I think it is
wonderful.
 
 Second, it might be worth pushing a 7.2.2 release containing 
 the fix for this bug, as well as the datetime problem. If 
 that sounds reasonable to the people who have to do the most 
 work on a new release (e.g. Marc), I can volunteer to 
 backport a fix for the datetime problem.

Bugs that cause a catastrophic error (e.g. crash of the database
engine, causing loss of data) should have the highest priority.  Call
them category zero.
Bugs that cause incorrect results should have the next highest priority.
Call them category one.
Bugs that are minor annoyances (e.g. appearance such as a misspelled
word in a help file) should be low priority.
Bugs that are only suggestions for improvements should have the lowest
priority.

All known category zero and one bugs should be fixed before each and
every new release.  IMO-YMMV.


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in

2002-08-20 Thread Vince Vielhaber

On 20 Aug 2002, Neil Conway wrote:

 Vince Vielhaber [EMAIL PROTECTED] writes:
  Here's yet another.

 Should someone from the core team perhaps get in contact with this guy
 and ask if he could get in contact with the development team before
 publicizing any further security holes? AFAIK that is standard
 operating procedure in most cases...

I just asked him/her that on bugtraq.

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  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==




---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows inPostgreSQL. (fwd)

2002-08-20 Thread Dann Corbit

 -Original Message-
 From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] 
 Sent: Tuesday, August 20, 2002 1:48 PM
 To: [EMAIL PROTECTED]
 Subject: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple 
 buffer overflows inPostgreSQL. (fwd)
 
 
 
 And another one.  Sure would be nice if shit-for-brains would 
 mention it to us first.

It looks to me like he may be the most valuable tester on the staff.
As long as we find out what the problem is, why complain?

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

2002-08-20 Thread Neil Conway

Tom Lane [EMAIL PROTECTED] writes:
 Neil Conway [EMAIL PROTECTED] writes:
  +   /* Check for integer overflow */
  +   if (tlen / slen != count)
  +   elog(ERROR, Requested buffer is too large.);
 
 What about slen == 0?

Good point -- that wouldn't cause incorrect results or a security
problem, but it would reject input that we should really accept.

Revised patch is attached.

Cheers,

Neil

-- 
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC


Index: src/backend/utils/adt/oracle_compat.c
===
RCS file: /var/lib/cvs/pgsql-server/src/backend/utils/adt/oracle_compat.c,v
retrieving revision 1.38
diff -c -r1.38 oracle_compat.c
*** src/backend/utils/adt/oracle_compat.c	20 Jun 2002 20:51:45 -	1.38
--- src/backend/utils/adt/oracle_compat.c	20 Aug 2002 20:51:20 -
***
*** 997,1002 
--- 997,1006 
  	slen = (VARSIZE(string) - VARHDRSZ);
  	tlen = (VARHDRSZ + (count * slen));
  
+ 	/* Check for integer overflow */
+ 	if (slen != 0  count != 0  tlen / slen != count)
+ 		elog(ERROR, Requested buffer is too large.);
+ 
  	result = (text *) palloc(tlen);
  
  	VARATT_SIZEP(result) = tlen;



---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows inPostgreSQL. (fwd)

2002-08-20 Thread Dann Corbit

 -Original Message-
 From: Frank Wiles [mailto:[EMAIL PROTECTED]] 
 Sent: Tuesday, August 20, 2002 1:57 PM
 To: Dann Corbit
 Cc: [EMAIL PROTECTED]
 Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: 
 Multiple buffer overflows inPostgreSQL. (fwd)
 
 
  .--[ Dann Corbit wrote (2002/08/20 at 13:54:53) ]--
  | 
  |   From: Vince Vielhaber [mailto:[EMAIL PROTECTED]] 
  |   Sent: Tuesday, August 20, 2002 1:48 PM
  |   To: [EMAIL PROTECTED]
  |   Subject: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple 
  |   buffer overflows inPostgreSQL. (fwd)
  |   
  |   
  |   
  |   And another one.  Sure would be nice if shit-for-brains would 
  |   mention it to us first.
  |  
  |  It looks to me like he may be the most valuable tester on 
 the staff.  |  As long as we find out what the problem is, 
 why complain?  |  
  `-
 
 The reason to complain is that he is not notifying the development
 team before hand. Giving them absolutely no chance to work on a
 fix prior to the whole world freaking out over these bugs. 
 
 If I was your neighbor, and I noticed your front door was open I
 would contact you and let you know... not take out a full page
 ad in the local news paper! Same idea applies here. :) 
 
 Also, if I'm not mistaken this guy isn't on staff. 

Well, of course, a well mannered team member would report the bugs
through one of the normal channels.
On the other hand, a malicious tester who finds these problems performs
two valuable services:
1.  Through great effort, he has found a problem that needs to be
addressed or serious consequences will result.
2.  He has raised a large public rancor.  The result of which is that
the serious problem must be addressed.

The motivation is suspect.  The character is suspect.  But the result is
of great value.  In a similar manner, it is a common practice to hire
hackers to try to break into your site.  While their methods will be
unconventional, and they can be very seedy and immoral characters, they
will reveal information of great value to show you exactly where the
hole needs to be plugged.

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)

2002-08-20 Thread Tom Lane

Vince Vielhaber [EMAIL PROTECTED] writes:
 And another one.  Sure would be nice if shit-for-brains would mention
 it to us first.

I don't even mind the first part, but it would certainly be polite of
him to cc: pghackers rather than expecting us to dig it off bugtraq.

But, as someone else pointed out, he's not doing this for our benefit,
it's to make himself look good.  The only audience he cares about is
bugtraq, I suspect.

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows inPostgreSQL. (fwd)

2002-08-20 Thread Frank Wiles

 .--[ Dann Corbit wrote (2002/08/20 at 14:05:37) ]--
 | 
 |  ... [large snip] ... 
 |
 |  Well, of course, a well mannered team member would report the bugs
 |  through one of the normal channels.
 |  On the other hand, a malicious tester who finds these problems performs
 |  two valuable services:
 |  1.  Through great effort, he has found a problem that needs to be
 |  addressed or serious consequences will result.
 |
 |  ... [small snip] ...
 |
 `-

Reading the TODO list is great effort? What puzzles me most is
that you speak as if you have personal knowledge of how much effort
it took. 

 -
   Frank Wiles [EMAIL PROTECTED]
   http://frank.wiles.org
 -


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)

2002-08-20 Thread Neil Conway

Vince Vielhaber [EMAIL PROTECTED] writes:
 And another one.

This patch should fix the problem. Doesn't include my previous patch
for repeat(). Again, somewhat off-the-cuff, so I might have missed
something...

test=# select lpad('x',1431655765,'');
ERROR:  Requested length too large
test=# select rpad('x',1431655765,'');
ERROR:  Requested length too large

(That's on a Unicode DB, haven't tested other encodings but AFAICT
this fix should still work.)

Cheers,

Neil

-- 
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC


Index: src/backend/utils/adt/oracle_compat.c
===
RCS file: /var/lib/cvs/pgsql-server/src/backend/utils/adt/oracle_compat.c,v
retrieving revision 1.38
diff -c -r1.38 oracle_compat.c
*** src/backend/utils/adt/oracle_compat.c	20 Jun 2002 20:51:45 -	1.38
--- src/backend/utils/adt/oracle_compat.c	20 Aug 2002 21:04:07 -
***
*** 199,204 
--- 199,209 
  
  #ifdef MULTIBYTE
  	bytelen = pg_database_encoding_max_length() * len;
+ 
+ 	/* check for integer overflow */
+ 	if (len != 0  bytelen / pg_database_encoding_max_length() != len)
+ 		elog(ERROR, Requested length too large);
+ 
  	ret = (text *) palloc(VARHDRSZ + bytelen);
  #else
  	ret = (text *) palloc(VARHDRSZ + len);
***
*** 310,315 
--- 315,325 
  
  #ifdef MULTIBYTE
  	bytelen = pg_database_encoding_max_length() * len;
+ 
+ 	/* Check for integer overflow */
+ 	if (len != 0  bytelen / pg_database_encoding_max_length() != len)
+ 		elog(ERROR, Requested length too large);
+ 
  	ret = (text *) palloc(VARHDRSZ + bytelen);
  #else
  	ret = (text *) palloc(VARHDRSZ + len);



---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer

2002-08-20 Thread Vince Vielhaber

On 20 Aug 2002, Neil Conway wrote:

 Vince Vielhaber [EMAIL PROTECTED] writes:
  And another one.

 This patch should fix the problem. Doesn't include my previous patch
 for repeat(). Again, somewhat off-the-cuff, so I might have missed
 something...

 test=# select lpad('x',1431655765,'');
 ERROR:  Requested length too large
 test=# select rpad('x',1431655765,'');
 ERROR:  Requested length too large

 (That's on a Unicode DB, haven't tested other encodings but AFAICT
 this fix should still work.)

Is there any chance that pg_database_encoding_max_length() could return
zero and give a divide by zero error?  Or is that trapped?

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  http://www.cloudninegifts.com
   http://www.meanstreamradio.com   http://www.unknown-artists.com
==




---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)

2002-08-20 Thread Neil Conway

Vince Vielhaber [EMAIL PROTECTED] writes:
 On 20 Aug 2002, Neil Conway wrote:
 Is there any chance that pg_database_encoding_max_length() could return
 zero and give a divide by zero error?  Or is that trapped?

I don't think so (the array of encodings that contains the data seems
to be pre-defined), but I know next to nothing about multibyte, so I
may be wrong. In any case, the divide by zero error would cause an
elog(ERROR) anyway, not a segfault...

Cheers,

Neil

-- 
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



[HACKERS] Multiple vulnerabilities in PostgreSQL

2002-08-20 Thread Justin Clift

Hi Mordred,

Thanks for doing this testing for vulnerabilities for us.

Some PostgreSQL team members have been looking to organise an audit
team to remove vulnerabilities like this, and your posts to BugTraq have
assisted in getting that further mobilised.

Something that is concerning us though, is that whilst one of these bugs
was known and on our to fix list, there are some that were not known
and you're not notifying us up front so we can fix them before details
are publicly released.

Would you be able to work in with us from here, notifying us of these
vulnerabilities with some decent amount of time in advance so we can
create the necessary patches/fixes, etc?

:-)

Regards and best wishes,

Justin Clift

-- 
My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there.
   - Indira Gandhi

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] [BUGS] Long strings, short varchars

2002-08-20 Thread Peter Eisentraut

Tom Lane writes:

 In any case we need to distinguish implicit coercion for a store from
 explicit coercion.  Do your recent pg_cast changes make that any easier?

Possibly we could allow for registering both implicit and explicit cast
functions for the same combination.  Or we could make cast functions take
an optional second argument that tells whether the cast is implicit or
explicit.  We probably also need to take into account the typemod coercion
functions that are currently handled in a semi-internal way.  (Any
formalization of those should probably consider the possibility of
allowing typemods on arbitrary types.)  Not sure which way to go.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] CREATE CAST WITHOUT FUNCTION should require superuserness?

2002-08-20 Thread Tom Lane

Peter Eisentraut [EMAIL PROTECTED] writes:
 Tom Lane writes:
 Also, in the present state of the code a WITHOUT FUNCTION cast does
 not work if AS ASSIGNMENT isn't given: parse_coerce.c won't ever find
 it.  Is this intentional, or just an oversight?

 It's a transition state that might be inadequately documented.

Okay.  Are you intending to work on it?  I was thinking of doing some
cleanup work in parse_coerce, but will refrain from joggling your elbow
if you're going to deal with it.

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Tom Lane

Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
 Would it be possible to update the system tables, so that cash_out does not take
 opaque but really takes type money ?

That is part of the solution, but only part: we have hundreds of
functions that take opaque because we don't currently have any way
to declare what they really take.  (In particular, all the typinput
functions are like that --- so fixing typoutput functions isn't plugging
even half of the gap.)

See my proposal to make opaque obsolete.

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] Large file support available

2002-08-20 Thread Tom Lane

Peter Eisentraut [EMAIL PROTECTED] writes:
 Large file support is now compiled by default if available.

I am now getting (on HPUX 10.20)

/usr/include/sys/resource.h: In function `getrlimit':
/usr/include/sys/resource.h:168: warning: implicit declaration of function 
`__getrlimit64'
/usr/include/sys/resource.h: In function `setrlimit':
/usr/include/sys/resource.h:170: warning: implicit declaration of function 
`__setrlimit64'

for essentially every file in the system.  A little digging shows that
this is happening because _FILE64 is defined and _LARGEFILE64_SOURCE
is not; this is evidently a Bad Idea on HPUX.

Further digging shows that noplace in the standard headers is
_LARGEFILE64_SOURCE #define'd, so evidently one is supposed to supply it
from user headers.  Ugh.  Please add this to the list of
platform-specific symbols that had better be turned on to support large
files.

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Zeugswetter Andreas SB SD


 Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
  Would it be possible to update the system tables, so that cash_out does not take
  opaque but really takes type money ?
 
 That is part of the solution, but only part: we have hundreds of
 functions that take opaque because we don't currently have any way
 to declare what they really take.

So the idea is, that input functions take cstring type, and output functions 
take the explicit type they are designed for ?
Is there anything that can be done vs that types only exist after the functions ?
e.g. create it in one tx with constraints deferred ? Or is that no issue ?

  (In particular, all the typinput
 functions are like that --- so fixing typoutput functions isn't plugging
 even half of the gap.)
 
 See my proposal to make opaque obsolete.

Yes, it is great that you will look into this !!
About the names, would it be good to use SQL99 reserved words ? (e.g. ROW for tuple) 
nice url: http://developer.mimer.se/validator/sql-reserved-words.tml

count(*)-- anynumeric  :-) (two flies with one strike)
NULL/NONNULL-- null|nullvalue|anynull ? We only need this internally, no ?

Hard to say what is good for those names imho, don't like anytype :-(
(maybe even leave that opaque for now)

I like cstring, void and internal. 
Maybe anyarray instead of anyarraytype.
And I would prefer row instead of tuple.

Andreas

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] Large file support available

2002-08-20 Thread Tom Lane

Also, even with configure --disable-largefile, I find that pg_config.h
still contains

/* Define to 1 to make fseeko visible on some hosts. */
#define _LARGEFILE_SOURCE 1

/* Define to 1 if fseeko (and presumably ftello) exists and is declared. */
#define HAVE_FSEEKO 1

This strikes me as probably Not a Good Thing, although I haven't dug to
see what the implications are.

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Tom Lane

Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
 Hard to say what is good for those names imho, don't like anytype :-(

How about any?  It's a reserved word per SQL99, I think.

 I like cstring, void and internal. 

Okay.

 Maybe anyarray instead of anyarraytype.

That would match with any.

 And I would prefer row instead of tuple.

I'm leaning towards agreeing with Stephan: we should use typename
trigger to declare triggers.  Tuple (or row) is strictly correct
only for BEFORE triggers, not AFTER triggers, so it's a bit of a
misnomer for triggers anyhow.

I'm now also toying with inventing a pseudotype just for procedural
language handlers, which are currently foo() returns opaque.  If we
want the type system to catch misuses of trigger functions, we should
want it for handlers too.  Maybe name this type language_handler?
(I had thought we could declare handlers to return internal, but we
can't do that without breaking type safety.  We don't want *any* way
for an SQL construct to look like it returns type internal.)

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Zeugswetter Andreas SB SD


 Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
  Hard to say what is good for those names imho, don't like 
 anytype :-(
 
 How about any?  It's a reserved word per SQL99, I think.

I would actually stick to opaque in that case, already used in other db's.

  I like cstring, void and internal. 
 
 Okay.
 
  Maybe anyarray instead of anyarraytype.
 
 That would match with any.

I thought you wanted it separate ?

 
  And I would prefer row instead of tuple.
 
 I'm leaning towards agreeing with Stephan: we should use typename
 trigger to declare triggers.  Tuple (or row) is strictly correct
 only for BEFORE triggers, not AFTER triggers, so it's a bit of a
 misnomer for triggers anyhow.

Convinced.

 
 I'm now also toying with inventing a pseudotype just for procedural
 language handlers, which are currently foo() returns opaque.  If we
 want the type system to catch misuses of trigger functions, we should
 want it for handlers too.  Maybe name this type language_handler?

HANDLER would again already be a reserved word, sounds good.

Andreas

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Tom Lane

Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
 Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
 Hard to say what is good for those names imho, don't like 
 anytype :-(
 
 How about any?  It's a reserved word per SQL99, I think.

 I would actually stick to opaque in that case, already used in other db's.

I want to change the name because (a) we are changing the semantics,
(b) we can't throw notices for opaque if we keep it as a valid choice.

 Maybe anyarray instead of anyarraytype.
 
 That would match with any.

 I thought you wanted it separate ?

I meant that if the one name is any, then making the other anyarray
(ie, both without type on the end) is consistent.

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] bison news

2002-08-20 Thread Bruce Momjian


OK, now that _a_ bison exists that works, how does this effect our
release?  I don't see preproc.[ch] in CVS.  Do we need this new bison
version on postgresql.org because Marc generates these as part of his
install script?

---

Tom Lane wrote:
 Michael Meskes [EMAIL PROTECTED] writes:
  On Tue, Aug 20, 2002 at 11:10:01AM -0400, Tom Lane wrote:
  BTW, I spent some time looking at the problem, and it seems the issue
  is not overrun of any bison internal table, but failure to compress the
  resulting action table into 32K entries.  This means that the required
 
  Ouch! This of course is not so much a problem for ecpg but for the
  backend should we run into the problem there too.
 
 As of CVS tip a few days ago, the backend's action table was about 27K
 entries.  So we have some breathing room, but certainly in the
 foreseeable future there will be a problem...
 
   regards, tom lane
 
 ---(end of broadcast)---
 TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread ngpg

[EMAIL PROTECTED] (Greg Copeland) wrote

 Time and time again I've read what basically amounts to, ...if someone
 can crash it it's because someone is stupid enough to allow someone to
 be able to do it in the first place...  Maybe you're right.  After all,
 if core developers continue to turn a blind eye to such issues, they are
 in fact, the facilitators of allowing people to do it to begin with.=20
 That is, they are the ones that allowing people to do it in the first
 place.  In short, every time I see that response, I immediately think,
 ...now that's the pot calling the kettle black.
 
 At some point in time, you have to stand and say, the buck stops here.
 

I agree here, but at the same time you cannot put 100% of the 
responsibility on the developers.  If you are the dba/sysadmin/whatever/etc 
then it is your responsibility.  It is up to you to know about potential 
problems and have workarounds or whatever it is you need to do.  I think 
that is one of the things that seperates a good admin from a not-so-
good one.

Afterall, when your boss calls you into his office monday morning and asks 
for a really good explanation for why the db was cracked, I dont think he 
is going to accept the excuse this guy, you dont know him but his name is 
tom lane.. well anyway, he didnt fix this bug i knew about so i didnt do 
nothing about it because i shouldnt have to because that would be like the 
pot calling the kettle black

That being said, I do agree the developers should give things like this 
more priority.  But, its open source...  so you either live with it or 
write your own patch.

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] Proposal: make opaque obsolete

2002-08-20 Thread Bruce Momjian

Tom Lane wrote:
  I think we should throw the notices right away, although this makes me
  wonder in general about upgrade path.  Are we ever planning to make that
  an error, and if so, how are we going to handle functions that are coming
  from previous versions where it was okay?
 
 We can't make it an error until sufficiently far down the road that we
 don't care about forward compatibility from 7.2-or-before dump files.
 That'll be a long while, probably.
 
 Throwing a notice right away is okay with me personally, but I wanted to
 see what other people thought...

NOTICE seems good.  We will have all this mentioned in the release notes
too.  In fact, we can point to the release notes in the NOTICE if
desired.

I like the array storage format change too.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Zeugswetter Andreas SB SD

  Hard to say what is good for those names imho, don't like 
  anytype :-(
  
  How about any?  It's a reserved word per SQL99, I think.
 
  I would actually stick to opaque in that case, already used in other db's.
 
 I want to change the name because (a) we are changing the semantics,
 (b) we can't throw notices for opaque if we keep it as a valid choice.

Hmm, any would sound like it is the same as opaque. Would any really be
all allowed types ? I think we would want to eliminate that altogether.
If it is not all types I would rather use a more restrictive name (nulltype 
/ anynumeric).
 
Imho opaque is missing a runtime type info, like a descriptor, 
and thus only pass by value could not be allowed anymore.

I guess I must sleep over this, not convinced about depricating opaque yet :-)

 I meant that if the one name is any, then making the other anyarray
 (ie, both without type on the end) is consistent.

Ah, good.

Andreas

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Rod Taylor

On Tue, 2002-08-20 at 16:46, Zeugswetter Andreas SB SD wrote:
   Hard to say what is good for those names imho, don't like 
   anytype :-(
   
   How about any?  It's a reserved word per SQL99, I think.
  
   I would actually stick to opaque in that case, already used in other db's.
  
  I want to change the name because (a) we are changing the semantics,
  (b) we can't throw notices for opaque if we keep it as a valid choice.
 
 Hmm, any would sound like it is the same as opaque. Would any really be
 all allowed types ? I think we would want to eliminate that altogether.

Erm.. count(*) - * is literally anything.


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL

2002-08-20 Thread Bruce Momjian

Vince Vielhaber wrote:
 
 Here's yet another.  He claims malicious code can be run on the server
 with this one.

 --[ Solution
 
 Do you still running postgresql? ...Can't believe that...
 If so, execute the following command as a root: killall -9 postmaster,
 and wait until the patch will be available.

You've got to love this last part.  ;-)

This has the attitude of Oh, look at me, I found a bug.  Let me
publicize it and get more attention.  Aren't you proud of me?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



[HACKERS] pgstattuple change using SRF

2002-08-20 Thread Tatsuo Ishii

I'm going to change contrib/pgstattuple so that it returns a tuple
rather than a NOTICE using new SRF interface. I believe this way is
much more convenient for users. Any objection?
--
Tatsuo Ishii

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL

2002-08-20 Thread Bruce Momjian

Dann Corbit wrote:
  -Original Message-
  From: Neil Conway [mailto:[EMAIL PROTECTED]] 
  Sent: Tuesday, August 20, 2002 1:44 PM
  To: Vince Vielhaber
  Cc: [EMAIL PROTECTED]
  Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: 
  Buffer overflow in PostgreSQL (fwd)
  
  
  Vince Vielhaber [EMAIL PROTECTED] writes:
   Here's yet another.
  
  Should someone from the core team perhaps get in contact with 
  this guy and ask if he could get in contact with the 
  development team before publicizing any further security 
  holes? AFAIK that is standard operating procedure in most cases...
 
 As long as we continue to find out about them, I would just let him work
 away.
 He is clearly an excellent tester, and if you had to hire him it would
 be very expensive.
 
 As long as he is producing results of such great value, I think it is
 wonderful.

Yea, someone please contact him and tell him to keep going.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Tom Lane

Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
 Hmm, any would sound like it is the same as opaque. Would any really be
 all allowed types ? I think we would want to eliminate that altogether.

Do you plan on eliminating the COUNT() aggregate, then?
 
 Imho opaque is missing a runtime type info, like a descriptor, 
 and thus only pass by value could not be allowed anymore.

AFAICS it's only useful for functions that only care whether their
argument is NULL or not, and don't inspect its value.  But that just
happens to describe COUNT, as well as nullvalue/nonnullvalue.

I don't really think that using ANY instead of OPAQUE for this purpose
will affect users, because they will never be declaring any functions
that would legitimately take ANY, much less return ANY (the latter
probably makes no sense at all).  It seems to me that COUNT, nullvalue,
and nonnullvalue pretty much cover the spectrum of what you can usefully
do with only an isnull bit to look at...

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in

2002-08-20 Thread Bruce Momjian


This is all an indication of our increasing usage.  Several PostgreSQL
articles have appeared in the past week in _major_ media outlets, not
just the open-source press (eweek, Bloomburg), a major PostgreSQL
support company bought a Linux distribution (SRA-Turbolinux), and we
have independent projects auditing our code.  It is only going to get
worse.  ;-)

---

Vince Vielhaber wrote:
 On 20 Aug 2002, Neil Conway wrote:
 
  Vince Vielhaber [EMAIL PROTECTED] writes:
   Here's yet another.
 
  Should someone from the core team perhaps get in contact with this guy
  and ask if he could get in contact with the development team before
  publicizing any further security holes? AFAIK that is standard
  operating procedure in most cases...
 
 I just asked him/her that on bugtraq.
 
 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  http://www.cloudninegifts.com
http://www.meanstreamradio.com   http://www.unknown-artists.com
 ==
 
 
 
 
 ---(end of broadcast)---
 TIP 5: Have you checked our extensive FAQ?
 
 http://www.postgresql.org/users-lounge/docs/faq.html
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] Proposal: make opaque obsolete

2002-08-20 Thread Joe Conway

Tom Lane wrote:
 About I/O behavior: the pg_type entries for these pseudo-types will have to
 have typinput and typoutput functions.  In general these I/O routines must
 just throw errors.  Otherwise you could break the intended type safety by
 supplying user-written constants.  For instance, the present definition of
 RECORD is wrong (sorry Joe) because it uses oidin and oidout; so I could
 write SELECT foo('42'::record) and thereby crash a function expecting
 RECORD.  Not that there will be any such function, but the analogous case
 with, say, INTERNAL would be bad news.

Sorry I've been unable to be very involved today. Anything you want me 
to do here?


 An exception is that void_out should succeed and just return an empty string;
 this allows functions-returning-void to be called by SELECT and behave
 reasonably.  Less obviously, void_in should succeed (and return nothing
 interesting, probably just a zero datum; it can ignore its input).  This
 allows plpgsql functions to be defined to return VOID.

This will be useful if/when we want to implement CALL stored_proc;


 Should we throw a NOTICE stating that opaque is deprecated if a trigger
 is declared with opaque?  Or should we wait a release or two for that?

I'd throw the NOTICE now.


Joe


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] Proposal: make opaque obsolete

2002-08-20 Thread Joe Conway

Tom Lane wrote:
 The reason I bring this up is that if we are changing the internal
 representation of arrays, we could add type OID and perhaps typmod to
 the array header, thus making an array value interpretable without any
 outside info.  Then you could actually do something interesting with
 a function taking anyarraytype.

This sounds very cool. I'd vote for that.

Joe



---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] pgstattuple change using SRF

2002-08-20 Thread Tom Lane

Tatsuo Ishii [EMAIL PROTECTED] writes:
 I'm going to change contrib/pgstattuple so that it returns a tuple
 rather than a NOTICE using new SRF interface. I believe this way is
 much more convenient for users. Any objection?

Sure.  I like the way Joe did show_all() better than the way Neil
did lock_status() --- I'm in the middle of getting rid of zero
type OIDs throughout the system, and so I'm not happy with anything
that re-introduces them, even if it's only transient during initdb.
Other than that minor point, go for it...

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] bison news

2002-08-20 Thread Bruce Momjian

Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  OK, now that _a_ bison exists that works, how does this effect our
  release?  I don't see preproc.[ch] in CVS.  Do we need this new bison
  version on postgresql.org because Marc generates these as part of his
  install script?
 
 I don't think we want a beta bison on postgres.org.  Let's see if we can
 hold out for a release...

Well, we had better get it on or it will get zero testing, and we _need_
it for the 7.3 release of ecpg, because as I remember, we didn't have
any other good backup plans.  ;-)

This may be a case where we have to do some beta testing on our own. I
will grab the bison beta myself for my machine.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] How to disable encoding validation during database restore

2002-08-20 Thread Tatsuo Ishii

 Hi Tatsuo Ishii :
 
 Thank you very much for your reply. Somehow I managed to restore the data by
 creating by database in  SQL_ASCII encoding. Then I changed the encoding of
 my database into EUC_CN thru update pg_database set encoding=2. But the
 same problem happened in vacuum verbose analyze. I went thru the changelog
 and found out that you have add the multibyte validation feature from
 release 7.2 on. Looks like the only way to get around is to patch the
 source.
 
 But I would like to suggest that this feature should be made configurable.
 You know encoding is a such a mess in the Chinese language,  the popular
 Chinese input methods actually allow the input of any Chinese character from
 different encodings(e.g., GB2312/GBK, big5), it is difficult to make sure
 that the user always input valid  characters unless you validate the insert
 and update clause.

But the encoding validation is made for such cases. It will prevent
the database from INSERT/UPDATE with wrong encoding data. If you
really want to allow input any GB2312/GBK, big5 etc. encoded data to
the database, why don't you simply use SQL_ASCII or some other single
byte encodings? If you mix up GB2312/GBK, big5 in a database you could
not perform sort or any other database operation properly anyway.
--
Tatsuo Ishii

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] pgstattuple change using SRF

2002-08-20 Thread Tatsuo Ishii

 Tatsuo Ishii [EMAIL PROTECTED] writes:
  I'm going to change contrib/pgstattuple so that it returns a tuple
  rather than a NOTICE using new SRF interface. I believe this way is
  much more convenient for users. Any objection?
 
 Sure.  I like the way Joe did show_all() better than the way Neil
 did lock_status() --- I'm in the middle of getting rid of zero
 type OIDs throughout the system, and so I'm not happy with anything
 that re-introduces them, even if it's only transient during initdb.
 Other than that minor point, go for it...

I think pgstattuple() never uses OPAQUE...
--
Tatsuo Ishii

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] Proposal: make opaque obsolete

2002-08-20 Thread Tom Lane

Joe Conway [EMAIL PROTECTED] writes:
 Tom Lane wrote:
 ...  Then you could actually do something interesting with
 a function taking anyarraytype.

 This sounds very cool. I'd vote for that.

Um, am I hearing a volunteer to make it happen?  I have other problems
I need to deal with ...

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] Build failure in current CVS

2002-08-20 Thread Tatsuo Ishii

 It looks like the new stuff for loadable conversion modules is not
 correct for building outside the source tree; it's being careless about
 the paths it uses to find files.  Tatsuo, can you fix that, or ask Peter
 for help?

I have applied following changes and am getting:

make: *** No rule to make target `ascii_and_mic.o', needed by 
`libascii_and_mic.so.0.0'.  Stop.

under one of a conversion directory. The weird thing is I do not get
this if I do a build inside the source tree. Any idea?

Index: proc.mk
===
RCS file: /cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/proc.mk,v
retrieving revision 1.2
diff -c -r1.2 proc.mk
*** proc.mk 8 Aug 2002 07:47:43 -   1.2
--- proc.mk 21 Aug 2002 06:09:13 -
***
*** 16,21 
  clean distclean maintainer-clean: clean-lib
$(RM) $(OBJS)
  
! include $(top_builddir)/src/Makefile.shlib
  
  all: $(shlib)
--- 16,21 
  clean distclean maintainer-clean: clean-lib
$(RM) $(OBJS)
  
! include $(top_srcdir)/src/Makefile.shlib
  
  all: $(shlib)
Index: ascii_and_mic/Makefile
===
RCS file: 
/cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/ascii_and_mic/Makefile,v
retrieving revision 1.1
diff -c -r1.1 Makefile
*** ascii_and_mic/Makefile  14 Aug 2002 02:45:10 -  1.1
--- ascii_and_mic/Makefile  21 Aug 2002 06:09:13 -
***
*** 8,11 
  
  NAME  := ascii_and_mic
  
! include ../proc.mk
--- 8,12 
  
  NAME  := ascii_and_mic
  
! include $(top_srcdir)/src/backend/utils/mb/conversion_procs/proc.mk
! 

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] SQL99 CONVERT() function

2002-08-20 Thread Peter Eisentraut

Tatsuo Ishii writes:

 Done. See current doc (user's guide 6.4. String Functions and
 Operators Table 6-7 Available conversion names) how I changed the
 conversion names.

What guideline did you follow?  For example, should koi8r be koi8_r?  Or
should winXXX be win_XXX?

-- 
Peter Eisentraut   [EMAIL PROTECTED]



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Oliver Elphick

On Tue, 2002-08-20 at 17:15, Tom Lane wrote:
 Yes it has.  CVS logs show
 
 2002-08-04 02:44  thomas
 
   * src/backend/utils/adt/: date.c, datetime.c, format_type.c,
   nabstime.c, timestamp.c, varlena.c: Add guard code to protect from
   buffer overruns on long date/time input  strings. [other
   comments pruned, but note this commit did a lot of other stuff too]
 
 The original argument was about whether we should push out a 7.2.2
 release just because of this fix.  AFAIK no one has even troubled to
 look at the patch and see whether it applies directly to the 7.2 branch;
 Thomas has revised the date/time code quite a bit since 7.2, so I'd
 expect that it's not going to apply exactly.

It doesn't.  I tried, since there's a Debian bug requesting those
patches be applied, but as far as I remember every hunk failed.
I didn't have time to try to make it fit.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 But I would not have you to be ignorant, brethren, 
  concerning them which are asleep, that ye sorrow not, 
  even as others which have no hope. For if we believe 
  that Jesus died and rose again, even so them also 
  which sleep in Jesus will God bring with him.
I Thessalonians 4:13,14 


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] [PATCHES] Patch for roll forward recovery (PITR)

2002-08-20 Thread Bruce Momjian


J.R, Richard, we only have 10 days until beta.  Can you give us any
status on PITR?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Mark Pritchard

On Tue, 20 Aug 2002 23:48, Greg Copeland wrote:
 On Tue, 2002-08-20 at 00:35, Dann Corbit wrote:
  Most computer virus problems are caused by buffer overrun.  Someone
  decided it wasn't very important.

 This is true.  IMO, it is extremely arrogant to ignore a buffer overrun
 and announce it can't be exploited.  There is many cases where this
 assertion has been proved to be false.  The real risk of overrun is not

I would certainly hope you are not misquoting me here. I have never stated we 
should ignore the bug. I suggested that with proper network level protection, 
the bug should not be exploitable.

If you did indeed misquote me, perhaps extreme arrogance in this case is the 
attribution of comments to people without basis?

 I agree with that too.  When setting priorities, using a scale of 1-10,
 10 being highest priority, anything that effects stability or
 reliability should always be a 10.  As such, they should always be
 repaired even above new wiz-bang features.

So, cutting through the self-supporting hyperbole, you believe that stability 
or reliability is more important than new features. I don't disagree. What I 
do disagree with is the panic mentality that seems so evident in this type 
of post.

If you have set up your production infrastructure in a sensible manner (of 
course sensible is open for interpretation), this bug does not affect you. 

This does highlight the root cause of our difference in opinions - I don't 
feel this is an issue because it doesn't affect me. You may be concerned by 
these issues because your infrastructure allows the general 'net using public 
to directly access your database. While I disagree with this 
configuration...it doesn't make you fundamentely wrong, simply different in 
our respective approaches.

 IMO, if you don't embrace that rule of thumb, a developer shouldn't be
 working on a project where stability and reliability are key components
 of the end product.

I wasn't aware that PostgreSQL as an open source collaborative project had any 
specific requirements of upon it at all. While stability and reliability are 
obvious goals, if you feel the project does not meet your needs you are more 
than welcome to try one of the alternatives. MySQL for example :)

Seriously though, its similar to the people who run Linus' kernels. Oh my god 
they say, the stable 2.4.x series has VM issues. We can't trust it anymore! 

Why are you using that kernel in the first place? Where has Linus said that 
this is suitable for production use? Stable does not mean production ready.

  potential overruns should be identified.  A grep for memcpy, strcpy,
  gets, etc. should hunt down most of them.  A known buffer overrun should
  fill the designer of a product with abject terror.  And I really mean

 Agreed.  It is horribly irresponsible to thumb a nose at such things in
 this day and age.

I'm not going to restate my previous response to this view, but I will ask, 
who is affected by the horribly irresponsible approach? If it is you, then 
why hasn't your due dilligence process audited the code? Perhaps you would 
feel more comfortable with one of the closed source/closed development model 
organisations? But what bugs lie within the depths of DBs such as SQL Server? 
How will you audit those? Or will you just trust the sales guy?

  programmers, but I am thinking of the damage that can be inflicted upon
  potential clients using the database.

 Not a question of it sounding negligent.  It is negligent.

 If quality and stability is not the core developers #1 goal then
 expecting people to trust the resulting product is laughable.  Please

Where is an expectation at all? If you want to use PostgreSQL, then use it. If 
it doesn't meet your needs, don't use it, or start fixing the issues 
yourself. If you can't do it, buy Oracle, or DB2, or whatever else.

 Time and time again I've read what basically amounts to, ...if someone
 can crash it it's because someone is stupid enough to allow someone to
 be able to do it in the first place...  Maybe you're right.  After all,
 if core developers continue to turn a blind eye to such issues, they are
 in fact, the facilitators of allowing people to do it to begin with.

I'm not sure how you make the jump from knowing that an issue exists and 
allowing people to exploit it, to the inference that core developers are 
turning a blind eye to it. Forgive me if I misquote you Tom, but I don't 
think he has ever said we should not fix this bug, simply that the effort 
is significant, and there are other factors to consider.

 You know, I've seen many people trash Oracle's unbreakable mantra.
 I'm sure no one is confused at the fact that it is nothing but a
 marketing ploy, however, perhaps there is a culture behind it.  Perhaps
 this is their way of saying stability and reliability is very important
 to them.  Perhaps their mantra is the rule of thumb outlined above.

Perhaps we need a pgsql-hackers-heated_discussions list so we can 

Re: [HACKERS] Build failure in current CVS

2002-08-20 Thread Tatsuo Ishii

 Tatsuo, why is there one directory per encoding combination with only one
 source file each?  Couldn't we put all the files in one directory?

euc_tw_and_big5 has *two* files. Also Unicode mapping files could be
moved to each directory. So the Unicode related functions might have
one more file. IMO giving a directory to each conversion
is more manageable than putting everything in single directory.
--
Tatsuo Ishii

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] Large file support available

2002-08-20 Thread Tatsuo Ishii

 Large file support is now compiled by default if available.  (Use
 --disable-largefile to turn it off.  That's what Autoconf gives us.)

Are you sure that backend gains more performance than 1GB segmented
file (I mean large file support turn on LET_OS_MANAGE_FILESIZE)? I
myself have not tried yet, but a linux kernel hacker around me gave
this question sometime ago.
--
Tatsuo Ishii

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow

2002-08-20 Thread Tatsuo Ishii

  test=# \df iso8859_1_to_utf8
List of functions
   Result data type |   Schema   |   Name|   Argument data types 
  
  
--++---+-
   integer  | pg_catalog | iso8859_1_to_utf8 | integer, integer, -, -, 
integer
 
 Right, that's what they are now, but what do the - entries really
 mean?  Also, are the integer args and result truthful, or do they
 really mean something else?

They are like:

 * conv_proc(
 *  INTEGER,-- source encoding id
 *  INTEGER,-- destination encoding id
 *  OPAQUE, -- source string (null terminated C string)
 *  OPAQUE, -- destination string (null terminated C string)
 *  INTEGER -- source string length

For the second and third argument they are actually treated as:

unsigned char *src = PG_GETARG_CSTRING(2);
unsigned char *dest = PG_GETARG_CSTRING(3);

The first one is an input parameter(source string), and second one is
an output parameter(destination string). The caller of this function
is responsible for allocationg enough memory for destination string.

The returned integer is actually dummy. The function always returns 1.
--
Tatsuo Ishii

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] backpatch of datetime fixes

2002-08-20 Thread Thomas Lockhart

Neil Conway wrote:
 
 I've backpatched Thomas's fixes for the potential buffer overruns in
 the datetime code to the REL7_2_STABLE branch. The required changes
 are pretty minimal, and the code passes the regression tests.
 
 However, I haven't yet seen a test-case that demonstrates the buffer
 overrun in 7.2 code (I originally found the problem when playing with
 datetime on 7.3-dev with integer datetimes)

I've had trouble provoking an error also, but the circumstances should
be related to having a long date/time input, especially if it has more
fields than one would expect in a valid date/time string.

 - Thomas

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] Proposal: make opaque obsolete

2002-08-20 Thread Christopher Kings-Lynne

 Trigger functions will now be expected to take no arguments and return
 either tuple (or trigger if we call it that) or opaque.  It would also be
 sensible to allow VOID in the case of AFTER triggers, but I'm inclined not
 to do so: I think it's better that a trigger function be declared in a way
 that makes it clear it's supposed to be a trigger.  If CREATE
 TRIGGER accepts
 functions returning void then I think you lose some useful error checking.

 Should we throw a NOTICE stating that opaque is deprecated if a trigger
 is declared with opaque?  Or should we wait a release or two for that?

I think a NOTICE at creation time is fine.

 Comments?

Sounds really good.

Chris


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)

2002-08-20 Thread Christopher Kings-Lynne

 Should someone from the core team perhaps get in contact with this guy
 and ask if he could get in contact with the development team before
 publicizing any further security holes? AFAIK that is standard
 operating procedure in most cases...

 Second, it might be worth pushing a 7.2.2 release containing the fix
 for this bug, as well as the datetime problem. If that sounds
 reasonable to the people who have to do the most work on a new release
 (e.g. Marc), I can volunteer to backport a fix for the datetime
 problem.

It'd be better to contact the dude and get all his bugs out of him, fix them
all and issue a 7.2.2 with all the fixes.

I think this is now essential - people will be using 7.2 series for ages
even after the 7.3 release...

Chris


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in

2002-08-20 Thread Gavin Sherry

On Wed, 21 Aug 2002, Christopher Kings-Lynne wrote:

  Should someone from the core team perhaps get in contact with this guy
  and ask if he could get in contact with the development team before
  publicizing any further security holes? AFAIK that is standard
  operating procedure in most cases...
 
  Second, it might be worth pushing a 7.2.2 release containing the fix
  for this bug, as well as the datetime problem. If that sounds
  reasonable to the people who have to do the most work on a new release
  (e.g. Marc), I can volunteer to backport a fix for the datetime
  problem.
 
 It'd be better to contact the dude and get all his bugs out of him, fix them
 all and issue a 7.2.2 with all the fixes.

That wouldn't work because it seems he is making advisories at the
time he discovers a bug/flaw. That is, he is not directly interested in
the robustness of Postgres -- rather, another poster put it, his
reputation on bugtraq. That's fine but it doesn't mesh well with the
co-ordinated effort you describe.

I still do not see this as being a serious security problem unless you are
providing access to postgres to untrusted users. The advisory's
recommendation of killing the postmaster as a solution to these bugs is
akin to saying 'kill ssh if there's a libc bug'. If you are providing
access to untrusted users, that advice is worthwhile. But if your users
are trusted and could produce the same effect in any other number of
reasons, the advice is useless.

As for making a 7.2.2 release for the sake of form and for those users who
do provide access to untrusted users (universities, ISPs, say) this would
be pointless without the changes to opaque which Tom has put forward and
may/may not work on before 7.3 beta. I'm not sure that the core guys would
be too happy doing that *and* requiring an initdb for a minor release (as 
I presume Tom's changes will require one).

Gavin


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] Build failure in current CVS (src/backend/utils/mb/conversion_procs)

2002-08-20 Thread Tom Lane

Tatsuo Ishii [EMAIL PROTECTED] writes:
 IMO giving a directory to each conversion
 is more manageable than putting everything in single directory.

I lean towards Peter's point here.  One or two files per conversion
is not unmanageable to keep in a single directory.  And I have noticed
that make and make install are visibly slower than before because
they have to recurse into all these new subdirectories.  I think the
accumulated developer time spent watching make will soon exceed any
possible benefit from splitting these files into subdirectories :-(

regards, tom lane

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in

2002-08-20 Thread Tom Lane

Tatsuo Ishii [EMAIL PROTECTED] writes:
 They are like:

  * conv_proc(
  *INTEGER,-- source encoding id
  *INTEGER,-- destination encoding id
  *OPAQUE, -- source string (null terminated C string)
  *OPAQUE, -- destination string (null terminated C string)
  *INTEGER -- source string length

Got it (shoulda read the documentation before asking ;-))

 The returned integer is actually dummy. The function always returns 1.

Yes.  I will change these to be declared as

foo(int, int, cstring, cstring, int) returns void

unless anyone has a problem with that?

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



[HACKERS] Trouble debugging contrib/fulltextindex

2002-08-20 Thread Christopher Kings-Lynne

Hi All,

Few quick questions.

1. How do you compile contribs with full debugging symbols.  I always get
heuristic-fencepost-blah probs with gdb even though I've configured postgres
with all the debugging stuff.  Makes it really hard to find probs in the
contribs.

2. Should contribs exclusively use palloc/pfree?  I notice that
fulltextindex is using malloc and free - is there any real reason not to
change them?

I've attached the current tarball (extract in contrib) but my regression
test is crashing and I've had to fill it full of elogs to see that nargs is
being overwritten by an overflow or something.

Florian - feel like helping me test/fix it.  go 'gmake install' and then
'gmake installcheck' to test it.

Thanks,

Chris



fulltextindex.tar.gz
Description: GNU Zip compressed data


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in

2002-08-20 Thread Neil Conway

Gavin Sherry [EMAIL PROTECTED] writes:
 As for making a 7.2.2 release for the sake of form and for those
 users who do provide access to untrusted users (universities, ISPs,
 say) this would be pointless without the changes to opaque which Tom
 has put forward and may/may not work on before 7.3 beta.

I don't think that releasing 7.2.2 without the opaque changes would be
pointless. For one thing, the opaque-related security problems are
comparatively minor: the cracker must be able to execute arbitrary SQL
commands against the database, and by that stage of the game, a DoS
attack is already trivial (e.g. disable GEQO and execute a 15 table
join query).

Also, from skimming the discussion on fixing the opaque problems,
there will be at least some degree of backwards incompatibility. That
is definitely undesirable for a stable point release -- as is an
initdb, as you point out. This amount of pain to fix a minor security
hole is *not* worth it, IMHO.

So I think that fixing the opaque problems in 7.2.x is simply
impossible. Given that, the question is whether we should make a 7.2.2
release with fixes for the other security holes (lpad(), rpad(),
reverse(), and the datetime overruns). IMHO, we should.

The datetime hole is fairly serious: it's not unreasonable for
developers to accept datetime input from the user without limiting
it's length. So it's quite likely that there are 7.2 systems in
production that have a sane security policy (e.g. hidden behind a
firewall, validate user input, etc.) that are still vulnerable.

The alternative seems unattractive: if we require that users wait for
7.3 to come out, it may be months before the 7.3.0 release. And even
then, upgrading to 7.3 is non-trivial: it requires an initdb and
reload, as well as testing to ensure that the user's applications run
smoothly on 7.3. Therefore, it may be several months before many
production sites upgrade to 7.3; leaving them in the cold for that
period isn't something I think we should do, if we can avoid it.

That said, there's only a limited amount that I can do. I think we
should make a 7.2.2 release, and to that end I've posted patches
against REL7_2_STABLE for all four of the security holes. The rest of
the work that goes into making a release needs to be done by others
(Marc, Vince, Bruce, etc.) -- if there's anything I can do to help,
let me know.

Cheers,

Neil

-- 
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



  1   2   >