Re: [HACKERS] Proposal: make opaque obsolete
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 ... Hmmm. I guess I should be careful what I wish for -- and plan to take some time-off from my day job between now and September 1st ;-) I'll give it a shot, but a crude gameplan/general guidance to get me started would be much appreciated. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Dropping a schema
I had a test schema containing one table. olly=# drop schema testing; NOTICE: table testing.testa depends on schema testing ERROR: Cannot drop schema testing because other objects depend on it Use DROP ... CASCADE to drop the dependent objects too This seems a little over-restrictive to me. There is no dependency outside the schema, so shouldn't that have worked? I should have thought CASCADE would be implicit for objects inside the schema to be dropped. -- 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 For the Lord himself shall descend from heaven with a shout, with the voice of the archangel, and with the trump of God; and the dead in Christ shall rise first; Then we which are alive and remain shall be caught up together with them in the clouds, to meet the Lord in the air; and so shall we ever be with the Lord. I Thessalonians 4:16,17 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] [Fwd: Re: Multiple vulnerabilities in PostgreSQL]
Hi guys, Sir Mordred seems okay, and is happy to help us out as long as we give him credit where it's due. Can't see where that would be a problem with anyone here, as it's totally in line with how we work, so am going to say yes to him up front. :-) Regards and best wishes, Justin Clift Original Message Subject: Re: Multiple vulnerabilities in PostgreSQL Date: Wed, 21 Aug 2002 08:12:15 + From: Sir Mordred The Traitor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi Justin. 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. There is no reason to be concerned really. While a bastard like me do stupid things sometimes, from now i will be working with you guys. I'll be posting to [EMAIL PROTECTED], and believe me, you will enough have time for fixing. After fixing, you will release an advisory and give me a credit. That will be enough for me. If that okay for you, let my know. Best regards. 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Multiple vulnerabilities in PostgreSQL
Hi Sir Mordred, Forwarded your email on to that same PostgreSQL Hackers mailing list (didn't seem to be anything confidential in it), just to let everyone know that things will be ok from here on, etc. No-one would generally even think to take credit for your work, as the people in our community are the decent up-front kind of folk, and we welcome your assistance and expertise in helping us find the vulnerabilities in PostgreSQL. So, yep, it's all cool with us. :-) Regards and best wishes, Justin Clift Sir Mordred The Traitor wrote: Hi Justin. 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. There is no reason to be concerned really. While a bastard like me do stupid things sometimes, from now i will be working with you guys. I'll be posting to [EMAIL PROTECTED], and believe me, you will enough have time for fixing. After fixing, you will release an advisory and give me a credit. That will be enough for me. If that okay for you, let my know. Best regards. 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 -- 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 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
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? Ah, you want it for aggbasetype in pg_aggregate, I did not see that. How could we then disallow it's use in other context ? Seems if there is no restriction, any will be exactly as prone to wrong use as opaque was. May be a plan could be to leave opaque, but throw a notice when it is used in a create stmt, like: NOTICE: the use of type OPAQUE should be avoided where possible Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] 7.3 TODO
Has anyone made a decision about the SET LOCAL needing to be changed to SET TRANSATION for SQL compatibiltity? Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] AT TIME ZONE bug in CVS?
What's with this? template1=# select current_timestamp(0); timestamptz 2002-08-21 16:39:40+08 (1 row) template1=# set time zone 'Australia/Sydney'; SET template1=# select current_timestamp(0); timestamptz 2002-08-21 18:39:49+10 (1 row) template1=# select current_timestamp(0) at time zone 'Australia/Sydney'; ERROR: Time zone 'australia/sydney' not recognized template1=# select current_timestamp(0) at time zone 'AEST'; timezone - 2002-08-21 18:40:07 (1 row) Shouldn't the textual version of the time zone work using 'at time zone' as well as 'set time zone'? And also, why does the column name change from timestamptz to timezone? Anyway, shouldn't it in fact be current_timestamp? Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] CVS broken - large file support?
On FreeBSD/Alpha, CVS gives: gmake[4]: Entering directory `/home/chriskl/pgsql-head/src/backend/parser' gmake[4]: Nothing to be done for `all'. gmake[4]: Leaving directory `/home/chriskl/pgsql-head/src/backend/parser' gcc -pipe -O -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../.. /src/interfaces/libpq -I../../../src/include -c -o common.o common.c -MMD In file included from common.c:21: pg_backup_archiver.h:168: syntax error before `off_t' gmake[3]: *** [common.o] Error 1 gmake[3]: Leaving directory `/home/chriskl/pgsql-head/src/bin/pg_dump' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/chriskl/pgsql-head/src/bin' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/chriskl/pgsql-head/src' gmake: *** [all] Error 2 Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Proposal: make opaque obsolete
On Wed, 21 Aug 2002, Tom Lane wrote: 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 ... Tom, I saw something in the other thread suggesting that you might be working on this. Is that so? If not I have had a little poke around the cash type but I'm no where near up to speed on the internals. Your proposal is that cstring etc. get entries like record on pg_type? That presumably means we'd need in and out functions defined for these, which in the case of cstring would just be copying the input to output? (As you can see I may not be the best person to work on this if it is to be available for the beta) -- 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] [SECURITY] DoS attack on backend possible
[EMAIL PROTECTED] writes: if you are going to be passing any user input to the database, you must/should validate in some manner before blindly passing it to the db. The db can and should guarantee data integrity, but the database cannot read your mind when it comes to how you structure your queries. [example of SQL injection attack deleted] This is not the problem at hand. SQL injection attacks can be avoided easily. Bugs in the conversion of strings to internal PostgreSQL objects are a different matter, though, and usually, devastating effects cannot be avoided by (reasonably complex) checks in the frontend. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: How could we then disallow it's use in other context ? Seems if there is no restriction, any will be exactly as prone to wrong use as opaque was. Well, you can always shoot yourself in the foot by creating a C function that misinterprets its input. I'm not here to prevent that. But it won't be easy to make a crashable function without superuser privileges, because all the PL languages will reject function definitions that use type ANY as an argument or result (ditto the other pseudotypes, except maybe VOID). May be a plan could be to leave opaque, but throw a notice when it is used in a create stmt, like: NOTICE: the use of type OPAQUE should be avoided where possible Right, that's exactly the plan. Actually, I think we can tighten the use of OPAQUE quite a bit, too. The only supported uses will be (a) as an argument or result of a datatype's I/O function, (b) as the result of a trigger function. Since I/O functions have to be coded in C anyway, we can disallow OPAQUE as an argument type of PL functions without losing any backwards compatibility. Furthermore, *we do not have to treat OPAQUE as meaning ANY*. It can become a pseudo-type that's not coercion-compatible to anything else, thus preventing any direct SQL calls of either I/O functions or triggers that are declared in the old style. There are still some holes, for example you could do select old_input_function(old_trigger_function()); and the type system wouldn't complain. But it's a lot more nearly watertight than before, even for functions declared with OPAQUE. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposal: make opaque obsolete
Nigel J. Andrews [EMAIL PROTECTED] writes: I saw something in the other thread suggesting that you might be working on this. Is that so? I am working on the main proposal to create pseudo-types. I was hoping to offload the bit about changing array representation, though. 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] Dropping a schema
Oliver Elphick [EMAIL PROTECTED] writes: olly=# drop schema testing; NOTICE: table testing.testa depends on schema testing ERROR: Cannot drop schema testing because other objects depend on it Use DROP ... CASCADE to drop the dependent objects too This seems a little over-restrictive to me. It's per spec: SQL92 saith 3) If RESTRICT is specified, then S shall not contain any per- sistent base tables, global temporary tables, created local temporary tables, views, domains, assertions, character sets, collations, or translations. Note: If CASCADE is specified, then such objects will be dropped by the effective execution of the SQL schema manipulation state- ments specified in the General Rules of this Subclause. Also, it seems the safest behavior to me. rmdir dir won't remove a nonempty directory; isn't that a pretty close analogy? 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] 7.3 TODO
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Has anyone made a decision about the SET LOCAL needing to be changed to SET TRANSATION for SQL compatibiltity? I think we had decided not to; IIRC the argument that spelling it TRANSACTION would be more spec-compatible looked bogus on closer inspection. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CVS broken - large file support?
Christopher Kings-Lynne [EMAIL PROTECTED] writes: On FreeBSD/Alpha, CVS gives [trouble] I'm currently having to use configure --disable-largefile on HPUX; looks like you'll have to do the same until Peter finishes ironing out the wrinkles with autoconfiguring largefile support. It would be helpful if you'd poke into your system headers and find out (a) can you do large files at all, and if so (b) what is the correct magic combination of #defines for your system. 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] Proposal: make opaque obsolete
Joe Conway [EMAIL PROTECTED] writes: I'll give it a shot, but a crude gameplan/general guidance to get me started would be much appreciated. AFAIK, the only code you should need to touch is in src/include/utils/array.h src/backend/utils/adt/arrayfuncs.c src/backend/utils/adt/arrayutils.c Look around for other references to ArrayType, but I don't *think* there is anything else that processes arrays directly; everything else should be calling construct_array() or deconstruct_array(). Adding an element-type OID field to the array header (ArrayType struct) ought to be a pretty straightforward exercise. We need to debate whether to store a typmod as well; I'm not sure that the space for it would be justified. The other thing that was bothering me was that the code is sloppy about alignment: although the overall start of the data area is correctly MAXALIGN'd, the offsets of individual data items in the array aren't necessarily made to be multiples of the element data type's alignment spec. This would probably result in core dumps for datatypes whose size is not a multiple of their alignment requirement. (The only standard one is INTERVAL. For reasons I've never quite figured out, an array of INTERVAL doesn't provoke core dumps; seems like it should, at least on machines where doubles actually require 8-byte alignment.) There are a dozen or two places in arrayfuncs.c that understand the alignment conventions for array elements, and they all need to be changed. The att_align macro in src/include/access/tupmacs.h is probably the thing to be using; look at the code in heaptuple.c to see how we position field values inside a tuple, and do likewise. 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] i'll promise, i'll be polite :-)
Hi. This post certainly contains no valuable information, but i feel i should clarify some points. 1) I like postgresql and i worked with it for a long time. 2) Solution like killall -9 postmaster was just a joke. 3) ...Hm..i forgot...maybe later ... 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
[HACKERS] @(#)Mordred Labs advisory 0x0002: Buffer overflow in PostgreSQL
Seems like this one was lost or was filtered out... //@(#)Mordred Labs advisory 0x0002 Release data: 19/08/02 Name: Buffer overflow in PostgreSQL Versions affected: all versions Risk: high --[ Description: There exists a buffer overflow in a SET TIME ZONE command, that allows an attacker to execute malicious code. --[ Details: Upon executing the SET TIME ZONE 'STRING' command, parse_timezone() function is invoked, which will overwrite a static buffer tzbuf with the supplied string. Look at the src/backend/commands/variable.c if you need something to laugh at. --[ How to reproduce: psql SET TIMEZONE to 'XX...very long string...X' ... NOTICE: Buffer Leak: [27191] (freeNext=0, freePrev=0, rel=0/0, blockNum=0, flags=0x0, refcount=0 128) NOTICE: Buffer Leak: [27192] (freeNext=0, freePrev=0, rel=0/0, blockNum=0, flags=0x0, refcount=0 1249) NOTICE: Buffer Leak: [27193] (freeNext=0, freePrev=0, rel=0/0, blockNum=0, flags=0x0, refcount=0 1651799137) NOTICE: Buffer Leak: [27194] (freeNext=0, freePrev=0, rel=0/0, blockNum=0, flags=0x0, refcount=0 1818326649) ... 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: Just wait... 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] i'll promise, i'll be polite :-)
On Wednesday 21 August 2002 10:42 am, Sir Mordred The Traitor wrote: Hi. This post certainly contains no valuable information, but i feel i should clarify some points. 1) I like postgresql and i worked with it for a long time. 2) Solution like killall -9 postmaster was just a joke. First, it is good you found the problems. However, you really should have notified the developers first. And giving joke advice as a solution isn't the height of responsibility. I have taken the liberty of addressing that issue on BugTraq, if it passes moderation. Having said that, I personally look forward to you telling us about problems you find, and helping audit this codebase. After all, if you found it someone else can too. But I hope you don't suffer too much for the repercussions that will undoubtedly be voiced here -- you did, afterall, make somewhat of a 'splash' when diving in. :-) -- 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
On Tue, 2002-08-20 at 18:40, Mark Pritchard wrote: 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. Don't think I quoted you at all. I don't see quotation marks and am including Dan's remark. Perhaps everyone isn't talking about you after all. Continue with the green pills. ;) do disagree with is the panic mentality that seems so evident in this type of post. Hmmm. Interesting. I didn't see panic or anything alarmist in my post. 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 :) In other words, if someone if verbal about development goals or objectives they should go elsewhere. As for specific requirements, I've said nothing which are not inherently obvious. Without a stable and reliable product, no one is going to use it for serious work. As such, it's certainly not a leap of faith to assume that developers without such ideals in mind should be shunned or properly guided. Why? Obviously (amazed I have to spell this out), said developer efforts would be counter to the project's objectives (stated or otherwise implicitly obvious). You also seem to imply that open source collaborative project[s] should not aim for high goals. I think it's safe to say, we disagree. 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? Hmm. Keep a blind and pretend it doesn't exist. Not a good response. Since this thread came out of someone's dilligence (coders or otherwise), I fail to see the significance of your comments. After all, mucho-peer review is supposed to be one of the perks of using OSS software. Considering I'm not asserted I'm performance a code audit, this seems completely unrelated to the topic at hand. 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. In other words, if someone if verbal about development goals they should go elsewhere. Furthermore, you seem to assert that only the core developers should be using this database. Wow, I'm amazed. Just because someone does or does not contributes code doesn't suddenly invalidate observations. That, of course, doesn't mean the observations have to be valid. Simply stated, if it meets my needs, shut-up and use it. If it doesn't, go elsewhere. Bad attitude. 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. Because it was stated that these are known issues. Because it was stated these have been known issues for a very long time. Because it was stated that, more or less, no one is excited about doing the lots of effort which is seemingly required to put some of these issues to bed. The expression, turning a blind eye, means that something is being ignored. It means it won't be focused on for now. That does not have to mean forever. The statement is valid and supported by pretty much every posting on this list on the topic at hand. I stand by my statement. Stop with the misquoting comments already. The quotes I used were properly attributed. Believe it or not, everyone is not talking about you or trying to place words in your mouth. Believe it or not, the quotes are correct. I have no idea what you're talking about. Perhaps we need a
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
On Tue, 2002-08-20 at 19:59, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Greg Copeland) wrote 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. I absolutely agree. I was not trying to say that bugs don't happen and that sometimes those bugs may cause crashes. What I was trying to say is what amounts to, dr, when I move my arm like this, it hurts, and the response is, don't do that. Humor aside, surely there has to be a happy medium in between. Perhaps, with a skewing toward fixing rather than prescribing. ;) 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 I understand and agree with ya. 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. Well, the priority portion was what I was shooting for. Perhaps it came off being over zealous. I'm not really sure. I re-read it and I didn't think so. But, I'm not you and you're not me...so, it's hard to say how exactly it was received. As for the open source comment, that fine and all...but...there are companies which are paying for postgres' development too. Some of the developers are being paid to do this. The write your own patch has much more meaning on simple projects. For a project as complex as postgres, simply asking for a patch is almost meaningless. Along those lines, I have been reading (code and the list) and learning for sometime now, as time allows. One day, I will contribute significant patches. However, until that day comes, I would hope that observational commentary is simply not invalidated just because they're not one with the code yet. Regards, Greg Copeland signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Proposal: make opaque obsolete
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: I'll give it a shot, but a crude gameplan/general guidance to get me started would be much appreciated. AFAIK, the only code you should need to touch is in src/include/utils/array.h src/backend/utils/adt/arrayfuncs.c src/backend/utils/adt/arrayutils.c Look around for other references to ArrayType, but I don't *think* there is anything else that processes arrays directly; everything else should be calling construct_array() or deconstruct_array(). OK. I should have a bit more time today and tonight. I'll see what I can get done with this. Thanks, Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Dropping a schema
On Wed, 2002-08-21 at 15:02, Tom Lane wrote: Oliver Elphick [EMAIL PROTECTED] writes: olly=# drop schema testing; NOTICE: table testing.testa depends on schema testing ERROR: Cannot drop schema testing because other objects depend on it Use DROP ... CASCADE to drop the dependent objects too This seems a little over-restrictive to me. It's per spec: SQL92 saith ... Also, it seems the safest behavior to me. rmdir dir won't remove a nonempty directory; isn't that a pretty close analogy? Not really, seeing that you can't say mkdir directory (containing these files). An implicit cascade *inside* the schema seems an appropriate parallel to CREATE SCHEMA ... (CREATE TABLE ...). After all, we don't have to say DROP TABLE ... CASCADE because the table has rows in it! But if that's what the spec says... -- 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 For the Lord himself shall descend from heaven with a shout, with the voice of the archangel, and with the trump of God; and the dead in Christ shall rise first; Then we which are alive and remain shall be caught up together with them in the clouds, to meet the Lord in the air; and so shall we ever be with the Lord. I Thessalonians 4:16,17 ---(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 0x0002: Buffer overflow in PostgreSQL
Sir Mordred The Traitor [EMAIL PROTECTED] writes:
There exists a buffer overflow in a SET TIME ZONE command, that
allows an attacker to execute malicious code.
Here's a patch for the problem. I also fixed some other potential
buffer overruns nearby, and added a little paranoia to another routine
that uses a statically sized buffer.
Thanks for the report.
Cheers,
Neil
--
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC
Index: src/backend/commands/variable.c
===
RCS file: /var/lib/cvs/pgsql-server/src/backend/commands/variable.c,v
retrieving revision 1.57
diff -c -r1.57 variable.c
*** src/backend/commands/variable.c 9 Dec 2001 04:37:50 - 1.57
--- src/backend/commands/variable.c 21 Aug 2002 16:07:54 -
***
*** 274,299
show_datestyle(void)
{
char buf[64];
- strcpy(buf, DateStyle is );
switch (DateStyle)
{
case USE_ISO_DATES:
! strcat(buf, ISO);
break;
case USE_SQL_DATES:
! strcat(buf, SQL);
break;
case USE_GERMAN_DATES:
! strcat(buf, German);
break;
default:
! strcat(buf, Postgres);
break;
! };
! strcat(buf, with );
! strcat(buf, ((EuroDates) ? European : US (NonEuropean)));
! strcat(buf, conventions);
elog(NOTICE, buf, NULL);
--- 274,299
show_datestyle(void)
{
char buf[64];
+ char *dstyle;
switch (DateStyle)
{
case USE_ISO_DATES:
! dstyle = ISO;
break;
case USE_SQL_DATES:
! dstyle = SQL;
break;
case USE_GERMAN_DATES:
! dstyle = German;
break;
default:
! dstyle = Postgres;
break;
! }
!
! snprintf(buf, sizeof(buf), DateStyle is %s with %s conventions,
! dstyle, EuroDates ? European : US (NonEuropean);
elog(NOTICE, buf, NULL);
***
*** 442,456
{
/* found something? then save it for later */
if ((defaultTZ = getenv(TZ)) != NULL)
! strcpy(TZvalue, defaultTZ);
/* found nothing so mark with an invalid pointer */
else
defaultTZ = (char *) -1;
}
! strcpy(tzbuf, TZ=);
! strcat(tzbuf, tok);
if (putenv(tzbuf) != 0)
elog(ERROR, Unable to set TZ environment variable to %s, tok);
--- 442,455
{
/* found something? then save it for later */
if ((defaultTZ = getenv(TZ)) != NULL)
! strncpy(TZvalue, defaultTZ, sizeof(TZvalue));
/* found nothing so mark with an invalid pointer */
else
defaultTZ = (char *) -1;
}
! snprintf(tzbuf, sizeof(tzbuf), TZ=%s, tok);
if (putenv(tzbuf) != 0)
elog(ERROR, Unable to set TZ environment variable to %s, tok);
***
*** 513,520
/* time zone was set and original explicit time zone available? */
else if (defaultTZ != (char *) -1)
{
! strcpy(tzbuf, TZ=);
! strcat(tzbuf, TZvalue);
if (putenv(tzbuf) != 0)
elog(ERROR, Unable to set TZ environment variable to %s, TZvalue);
tzset();
--- 512,518
/* time zone was set and original explicit time zone available? */
else if (defaultTZ != (char *) -1)
{
! snprintf(tzbuf, sizeof(tzbuf), TZ=%s, TZvalue);
if (putenv(tzbuf) != 0)
elog(ERROR, Unable to set TZ environment variable to %s, TZvalue);
tzset();
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] AT TIME ZONE bug in CVS?
template1=# select current_timestamp(0) at time zone 'Australia/Sydney'; ERROR: Time zone 'australia/sydney' not recognized The input is done using an internal lookup, not your system's time zone database. Much faster; setting time zone variables for every input will be substantially slower (though I haven't measured how much, it will involve opening files etc etc). And also, why does the column name change from timestamptz to timezone? Anyway, shouldn't it in fact be current_timestamp? The feature is implemented as a function call to timezone(), which returns a string. If it stayed a timestamp or something like that the time zone can not be frozen through the formatting/output process. - Thomas ---(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
May be a plan could be to leave opaque, but throw a notice when it is used in a create stmt, like: NOTICE: the use of type OPAQUE should be avoided where possible Right, that's exactly the plan. Actually, I think we can tighten the use of OPAQUE quite a bit, too. The only supported uses will be (a) as an argument or result of a datatype's I/O function, (b) as the result of a trigger function. In my paper I use C functions that take any tuple. I do not yet see how I can do that without opaque if we don't have a row but only a trigger type. Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Dropping a schema
Oliver Elphick [EMAIL PROTECTED] writes: On Wed, 2002-08-21 at 15:02, Tom Lane wrote: Also, it seems the safest behavior to me. rmdir dir won't remove a nonempty directory; isn't that a pretty close analogy? Not really, seeing that you can't say mkdir directory (containing these files). An implicit cascade *inside* the schema seems an appropriate parallel to CREATE SCHEMA ... (CREATE TABLE ...). After all, we don't have to say DROP TABLE ... CASCADE because the table has rows in it! Hm. I could see an argument for being willing to auto-drop stuff that had been made that way (inside CREATE SCHEMA) but not stuff that was made by separate commands. But the spec doesn't seem to make any such distinction: RESTRICT is RESTRICT. In any case, I like the behavior as it is, so I'm not gonna go out of my way to change 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 0x0003: Buffer overflow in
Robert Treat wrote: snip Assuming that we do go ahead with a 7.2.2 release, can we get some kind of unofficial statement on pushing back the 7.3 beta? I know Tom was hoping to start it by sept 1 but that seems rushed to me. Furthermore, between schema support and now more backward incompatibility in regards to functions/opaque, should we open some discussion on 7.3 really being 8.0? Depending on how far back we push this, we might be able to get Windows Native support added. That'd be cool and probably contribute to an 8.0. :) Regards and best wishes, Justin Clift Robert Treat ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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 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
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: In my paper I use C functions that take any tuple. I do not yet see how I can do that without opaque if we don't have a row but only a trigger type. For that you would have to use any, at the moment. This would give you the same amount of type safety you have with opaque, ie, none. We could talk about adding more pseudotypes that are geared to requirements not existing in the standard set of functions ... but I'm going to concentrate on those first. 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 0x0003: Buffer overflow in
We learned a few lessons from previous releases. First, don't delay the beta by days/weeks that drag on. Delay one month at a time. Second, don't decide on a further delay the day before you are going to go beta. Multiple short-period delays and delays that happen at the last minute cause too many stops/starts for developers to be effective, so... If we are going to delay beta, we should decide now, not at the end of August, and the delay should be until the end of September. The big question is whether we have enough material to warrant a delay. --- Justin Clift wrote: Robert Treat wrote: snip Assuming that we do go ahead with a 7.2.2 release, can we get some kind of unofficial statement on pushing back the 7.3 beta? I know Tom was hoping to start it by sept 1 but that seems rushed to me. Furthermore, between schema support and now more backward incompatibility in regards to functions/opaque, should we open some discussion on 7.3 really being 8.0? Depending on how far back we push this, we might be able to get Windows Native support added. That'd be cool and probably contribute to an 8.0. :) Regards and best wishes, Justin Clift Robert Treat ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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 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 -- 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
In my paper I use C functions that take any tuple. I do not yet see how I can do that without opaque if we don't have a row but only a trigger type. For that you would have to use any, at the moment. This would give you the same amount of type safety you have with opaque, ie, none. I would have to use some pg_proc magic to make any appear there, since the plan was to not make it visible at the sql level, no ? If you do, you would also have to throw the notice for any. Again, I think leaving any be opaque and throwing the warning NOTICE would be better. I do not think there is enough time to really see through the implications of restricting opaque already in 7.3, (at least for me :-) We could talk about adding more pseudotypes that are geared to requirements not existing in the standard set of functions ... but I'm going to concentrate on those first. Yes, certainly a lot of work. Andreas ---(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
delay beta ? (was: RE: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in)
If we are going to delay beta, we should decide now, not at the end of August, and the delay should be until the end of September. The big question is whether we have enough material to warrant a delay. I think the implicit casts todo should be adressed soon, not sure there is enough time for discussing this topic in 10 days ? Am I the only relic, that wants all implicit casts that don't cause loss of precision ? Nice ones would imho be such involving numeric constants, like select * from atab where int2col=2; -- use index on int2col Andreas ---(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 0x0003: Buffer overflow in
Bruce Momjian wrote: We learned a few lessons from previous releases. First, don't delay the beta by days/weeks that drag on. Delay one month at a time. Second, don't decide on a further delay the day before you are going to go beta. Multiple short-period delays and delays that happen at the last minute cause too many stops/starts for developers to be effective, so... If we are going to delay beta, we should decide now, not at the end of August, and the delay should be until the end of September. The big question is whether we have enough material to warrant a delay. Only two things which have the potential to be worth waiting for, from what I'm aware of. There may be others: - Find out from Sir Mordred if he wants to take a look at the CVS version of code and audit in that for a bit, Just In Case he turns up something that's serious and requires substantial re-work. Although it means he wouldn't have a bunch of I found this existing exploit type releases, we could instead offer him credit on the press release along the lines of This released has been audited for security flaws in its code by Sir Mordred. Am pretty sure he'd do a very thorough job for that, as it means he'd have an official product reputation he'd need to stand by for it. - Patches to the CVS tree which let us have a truly native windows version. This is of huge significance and would *very* much improve our growth and adoption by being in this release in comparison to being in the release afterwards. Not in an airy fairy way, but quite definitely and solidly. Of the two, Sir Mordred may or may not be willing, so that's kind of iffy, whereas the Windows Native port which is in beta testing isn't in too bad a state at all already. Have been running preliminary multi-user AS3AP tests on it (with OSDB) and getting a significant performance throughput increase in comparison to the cygwin version. :) Hope I'm not pushing too strongly for this, as, after all, I can't do the coding needed here. :( 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: For that you would have to use any, at the moment. This would give you the same amount of type safety you have with opaque, ie, none. I would have to use some pg_proc magic to make any appear there, since the plan was to not make it visible at the sql level, no ? Huh? It'll be perfectly visible. There is one little problem with calling it ANY, it turns out: that word is fully reserved in our parser (and trying to make it less reserved creates reduce/reduce conflicts). So unless we go back to anytype you'd have to quote the name, eg create function foo(any) returns ... I do prefer using any because that's what we have historically used in CREATE AGGREGATE, but maybe the keyword conflict will be too annoying. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
Justin Clift wrote: Only two things which have the potential to be worth waiting for, from what I'm aware of. There may be others: - Find out from Sir Mordred if he wants to take a look at the CVS version of code and audit in that for a bit, Just In Case he turns up something that's serious and requires substantial re-work. Although it means he wouldn't have a bunch of I found this existing exploit type releases, we could instead offer him credit on the press release along the lines of This released has been audited for security flaws in its code by Sir Mordred. Am pretty sure he'd do a very thorough job for that, as it means he'd have an official product reputation he'd need to stand by for it. This is interesting. He would have a month to do it. - Patches to the CVS tree which let us have a truly native windows version. This is of huge significance and would *very* much improve our growth and adoption by being in this release in comparison to being in the release afterwards. Not in an airy fairy way, but quite definitely and solidly. Of the two, Sir Mordred may or may not be willing, so that's kind of iffy, whereas the Windows Native port which is in beta testing isn't in too bad a state at all already. Have been running preliminary multi-user AS3AP tests on it (with OSDB) and getting a significant performance throughput increase in comparison to the cygwin version. OK, now I have to ask, where did this native Windows version come from? I don't know anything about it, except that Jan and SRA are both working on versions. The other issue is PITR, which I have been told today will not be ready for a September 1 beta but may be ready for an October 1 beta. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
Bruce Momjian wrote: Justin Clift wrote: Only two things which have the potential to be worth waiting for, from what I'm aware of. There may be others: - Find out from Sir Mordred if he wants to take a look at the CVS version of code and audit in that for a bit, Just In Case he turns up something that's serious and requires substantial re-work. Although it means he wouldn't have a bunch of I found this existing exploit type releases, we could instead offer him credit on the press release along the lines of This released has been audited for security flaws in its code by Sir Mordred. Am pretty sure he'd do a very thorough job for that, as it means he'd have an official product reputation he'd need to stand by for it. This is interesting. He would have a month to do it. Reckon it's worth asking him, to find out if he'd be interested in this? - Patches to the CVS tree which let us have a truly native windows version. This is of huge significance and would *very* much improve our growth and adoption by being in this release in comparison to being in the release afterwards. Not in an airy fairy way, but quite definitely and solidly. Of the two, Sir Mordred may or may not be willing, so that's kind of iffy, whereas the Windows Native port which is in beta testing isn't in too bad a state at all already. Have been running preliminary multi-user AS3AP tests on it (with OSDB) and getting a significant performance throughput increase in comparison to the cygwin version. OK, now I have to ask, where did this native Windows version come from? I don't know anything about it, except that Jan and SRA are both working on versions. It was kind of quietly let slip out: http://archives.postgresql.org/pgsql-cygwin/2002-08/msg00012.php But, it's definitely up and running and functional and pretty decent. :-) The other issue is PITR, which I have been told today will not be ready for a September 1 beta but may be ready for an October 1 beta. Useful, but not sure it's worth delaying even *further* for. + Justin -- 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 -- 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 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
Justin Clift wrote: Bruce Momjian wrote: Justin Clift wrote: Only two things which have the potential to be worth waiting for, from what I'm aware of. There may be others: - Find out from Sir Mordred if he wants to take a look at the CVS version of code and audit in that for a bit, Just In Case he turns up something that's serious and requires substantial re-work. Although it means he wouldn't have a bunch of I found this existing exploit type releases, we could instead offer him credit on the press release along the lines of This released has been audited for security flaws in its code by Sir Mordred. Am pretty sure he'd do a very thorough job for that, as it means he'd have an official product reputation he'd need to stand by for it. This is interesting. He would have a month to do it. Reckon it's worth asking him, to find out if he'd be interested in this? I wouldn't do it yet until we know if we are going to delay. - Patches to the CVS tree which let us have a truly native windows version. This is of huge significance and would *very* much improve our growth and adoption by being in this release in comparison to being in the release afterwards. Not in an airy fairy way, but quite definitely and solidly. Of the two, Sir Mordred may or may not be willing, so that's kind of iffy, whereas the Windows Native port which is in beta testing isn't in too bad a state at all already. Have been running preliminary multi-user AS3AP tests on it (with OSDB) and getting a significant performance throughput increase in comparison to the cygwin version. OK, now I have to ask, where did this native Windows version come from? I don't know anything about it, except that Jan and SRA are both working on versions. It was kind of quietly let slip out: http://archives.postgresql.org/pgsql-cygwin/2002-08/msg00012.php But, it's definitely up and running and functional and pretty decent. Oh, so it is Jan's group. Great news; wish someone would have told me sooner. I removed the Win32 off the open items list because, with no info and no one commenting on the item, it seemed dead for 7.3. The other issue is PITR, which I have been told today will not be ready for a September 1 beta but may be ready for an October 1 beta. Useful, but not sure it's worth delaying even *further* for. Well, PITR is a much more desired feature even than Win32; the big question is how long PITR will actually take, seeing as we haven't see any patches yet. However, we haven't seen any Win32 patches yet either, so they are in the same boat as far as I am concerned. We have an open items list that is pretty much ready for 7.3. The only open items of significance left is whether schema/DROP COLUMN stuff is ready in all the interfaces/apps. -- 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 P O S T G R E S Q L 7 . 3 O P E NI T E M S Current at ftp://candle.pha.pa.us/pub/postgresql/open_items. Source Code Changes --- Schema handling - ready? interfaces? client apps? Drop column handling - ready for all clients, apps? have pg_dumpall dump out db privilege and per-user/db settings fix implicit type coercions that are worse Prepared statements - to be reviewed (Tom) improve macros in new tuple header code (Tom) integrate or move to gborg libpqxx, Pg:DBD Allow PL/PgSQL functions to return sets (Neil) Allow easy display of usernames in a group (pg_hba.conf uses groups now) fix BeOS and QNX4 ports On Hold --- Point-in-time recovery - status? (J.R., Richard) Win32 port Security audit Documentation Changes - Mention foreign keys and SERIAL dependencies will not be in 7.2 loaded tables Document need to add permissions to loaded functions and languages ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
For that you would have to use any, at the moment. This would give you the same amount of type safety you have with opaque, ie, none. I would have to use some pg_proc magic to make any appear there, since the plan was to not make it visible at the sql level, no ? Huh? It'll be perfectly visible. I did not mean visible, I meant useable, like in create function xx(any) returns text ...; If that is possible, what is the difference to opaque ? Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CVS broken - large file support?
Christopher Kings-Lynne writes: On FreeBSD/Alpha, CVS gives: pg_backup_archiver.h:168: syntax error before `off_t' I have added sys/types.h, so off_t should now be available. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
On Wed, 2002-08-21 at 13:13, Bruce Momjian wrote: Justin Clift wrote: Bruce Momjian wrote: Justin Clift wrote: Only two things which have the potential to be worth waiting for, from what I'm aware of. There may be others: - Find out from Sir Mordred if he wants to take a look at the CVS version of code and audit in that for a bit, Just In Case he turns up something that's serious and requires substantial re-work. Although it means he wouldn't have a bunch of I found this existing exploit type releases, we could instead offer him credit on the press release along the lines of This released has been audited for security flaws in its code by Sir Mordred. Am pretty sure he'd do a very thorough job for that, as it means he'd have an official product reputation he'd need to stand by for it. This is interesting. He would have a month to do it. Reckon it's worth asking him, to find out if he'd be interested in this? I wouldn't do it yet until we know if we are going to delay. I'd ask anyway. 99% of the issues he finds will be fairly localized. Anything truly new (not on TODO already) will probably require a fair bit of time to track down, then fix time on top (2 months delay?). Anyway, these types of discoveries are better in beta than after the release and would still warrent a mention if there is a fair amount of ground covered. Personally, I'd be more interested in whats safe (covered) than whats broken. Posting the successful test cases as some proof rowards stability / security of the new release would realize immediate gains in settling nervous VPs about the new installation. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
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.)
Cheers,
Neil
--
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
--
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 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] CVS broken - large file support?
Peter, did you go around and remove sys/types.h from all the include files now that it is in c.h? --- Peter Eisentraut wrote: Christopher Kings-Lynne writes: On FreeBSD/Alpha, CVS gives: pg_backup_archiver.h:168: syntax error before `off_t' I have added sys/types.h, so off_t should now be available. -- Peter Eisentraut [EMAIL PROTECTED] ---(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 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
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: I did not mean visible, I meant useable, like in create function xx(any) returns text ...; If that is possible, what is the difference to opaque ? any will have the same behavior that opaque used to have, yes. 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
I did not mean visible, I meant useable, like in create function xx(any) returns text ...; If that is possible, what is the difference to opaque ? any will have the same behavior that opaque used to have, yes. Ok, now I vote, that you don't implement any and use opaque. I don't think we want two types that do the same thing. Is it that you like the name any more than opaque ? I am confused. Andreas ---(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
On 21 Aug 2002, Robert Treat wrote: Assuming that we do go ahead with a 7.2.2 release, can we get some kind of unofficial statement on pushing back the 7.3 beta? I know Tom was v7.3 goes beta Sept 1st ... v7.2.2 will be purely a security bugfix release, with no changes in functionality that should (I hope?) require anything more then a simple re-install ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
On Wed, 21 Aug 2002, Bruce Momjian wrote: We learned a few lessons from previous releases. First, don't delay the beta by days/weeks that drag on. Delay one month at a time. Second, don't decide on a further delay the day before you are going to go beta. Multiple short-period delays and delays that happen at the last minute cause too many stops/starts for developers to be effective, so... If we are going to delay beta, we should decide now, not at the end of August, and the delay should be until the end of September. The big question is whether we have enough material to warrant a delay. Beta goes down in 1 week ... if we follow what we had talked about before, within a short period of time after beta, we should be able to let ppl dive into working on v7.4 (or 8.0, whatever we decide to call it) ... but let's try and stick to a timeline for once, else we are going to hit the same as the last *very* extended release ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
On Thu, 22 Aug 2002, Justin Clift wrote: - Find out from Sir Mordred if he wants to take a look at the CVS version of code and audit in that for a bit, Just In Case he turns up something that's serious and requires substantial re-work. Although it means he wouldn't have a bunch of I found this existing exploit type releases, we could instead offer him credit on the press release along the lines of This released has been audited for security flaws in its code by Sir Mordred. Am pretty sure he'd do a very thorough job for that, as it means he'd have an official product reputation he'd need to stand by for it. Security Relatd Fixed are applicable for adoption during the beta period, leading up to release ... - Patches to the CVS tree which let us have a truly native windows version. This is of huge significance and would *very* much improve our growth and adoption by being in this release in comparison to being in the release afterwards. Not in an airy fairy way, but quite definitely and solidly. If they aren't in by now, they should wait until the next dev cycle ... unless they are *small* changes ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
On Wed, 2002-08-21 at 13:50, Marc G. Fournier wrote: On Wed, 21 Aug 2002, Bruce Momjian wrote: We learned a few lessons from previous releases. First, don't delay the beta by days/weeks that drag on. Delay one month at a time. Second, don't decide on a further delay the day before you are going to go beta. Multiple short-period delays and delays that happen at the last minute cause too many stops/starts for developers to be effective, so... If we are going to delay beta, we should decide now, not at the end of August, and the delay should be until the end of September. The big question is whether we have enough material to warrant a delay. Beta goes down in 1 week ... if we follow what we had talked about before, within a short period of time after beta, we should be able to let ppl dive into working on v7.4 (or 8.0, whatever we decide to call it) ... but let's try and stick to a timeline for once, else we are going to hit the same as the last *very* extended release ... Agreed. If patches are applied to the 7.4 branch as fast as normal, then maybe 7.4 will only be 6 months out with well tested Windows, PIT, etc. code that gets applied this October. Whats the intended branchpoint? Beta with less than 5 patches? 3rd beta start period? Less than 100 lines changed between betas? Where is the reasonable point where double patching isn't as annoying as waiting to apply new work? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
On Wed, 21 Aug 2002, Bruce Momjian wrote: Justin Clift wrote: Only two things which have the potential to be worth waiting for, from what I'm aware of. There may be others: - Find out from Sir Mordred if he wants to take a look at the CVS version of code and audit in that for a bit, Just In Case he turns up something that's serious and requires substantial re-work. Although it means he wouldn't have a bunch of I found this existing exploit type releases, we could instead offer him credit on the press release along the lines of This released has been audited for security flaws in its code by Sir Mordred. Am pretty sure he'd do a very thorough job for that, as it means he'd have an official product reputation he'd need to stand by for it. This is interesting. He would have a month to do it. A month in beta, ya ... or more, depending on how beta went ... but a 'Security Audit' shouldn' tlogically be done until the code base is frozen for Beta anyway, since who knows, if it isn't frozen, whether someone is going to introduce something else in the mean time ... The other issue is PITR, which I have been told today will not be ready for a September 1 beta but may be ready for an October 1 beta. Then it can wait for v7.4 ... period. Have we not learnt from past 'delays' ... hell, you yourself use may be ready for, so, what, Oct 1st rolls around and we delay for, say, another 2 weeks cause it may be ready for then? No ... if PITR and Native Windows aren't ready for inclusion, then they can be the foundation for the v7.4 release ... Sept 1st - 1st Beta ... Oct 1st is the tentative release date ... which gives Mordred a month to audit the code and report any security bugs before th release, where there are no substantive changes going into the code that will invalidate his results ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
On Wed, 21 Aug 2002, Bruce Momjian wrote: Justin Clift wrote: Reckon it's worth asking him, to find out if he'd be interested in this? I wouldn't do it yet until we know if we are going to delay. Any security audit of the code should *not* be done while the code is in flux, and if we delay, the code would be in flux since the delay would be to throw in a load of other code that would invalidate the audit results ... Oh, so it is Jan's group. Great news; wish someone would have told me sooner. I removed the Win32 off the open items list because, with no info and no one commenting on the item, it seemed dead for 7.3. And it should be ... we can put the Win32 patches up on the ftp site for ppl to play with if they want, but to include it at this late a date would be irresponsible ... Well, PITR is a much more desired feature even than Win32; the big question is how long PITR will actually take, seeing as we haven't see any patches yet. However, we haven't seen any Win32 patches yet either, so they are in the same boat as far as I am concerned. We have an open items list that is pretty much ready for 7.3. The only open items of significance left is whether schema/DROP COLUMN stuff is ready in all the interfaces/apps. We set a timeline for beta ... this time, let's stick to it ... its not like we didn't advertise when we were going into beta ... hell, even when the patches are presented for PITR support, who knows whether they will be accepted, or what kinda bugs they are going to throw into the mix, or ... ---(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 0x0002: Buffer overflow in PostgreSQL
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Neil Conway wrote: Sir Mordred The Traitor [EMAIL PROTECTED] writes: There exists a buffer overflow in a SET TIME ZONE command, that allows an attacker to execute malicious code. Here's a patch for the problem. I also fixed some other potential buffer overruns nearby, and added a little paranoia to another routine that uses a statically sized buffer. Thanks for the report. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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 0x0002: Buffer overflow in PostgreSQL
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Neil Conway wrote: Neil Conway [EMAIL PROTECTED] writes: Sir Mordred The Traitor [EMAIL PROTECTED] writes: There exists a buffer overflow in a SET TIME ZONE command, that allows an attacker to execute malicious code. Here's a patch for the problem. I also fixed some other potential buffer overruns nearby, and added a little paranoia to another routine that uses a statically sized buffer. The handling of the TZ environmental variable is subject to a buffer overrun. To see the problem, try: export TZ=XXXx postmaster -D /foo/bar psql You get: NOTICE: Buffer Leak: [26914] (freeNext=0, freePrev=0, rel=0/0, blockNum=0, flags=0x0, refcount=0 1) [ lots more NOTICEs ] psql: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. A revised patch is attached that fixes the problem. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC [ Attachment, skipping... ] ---(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 -- 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 0x0003: Buffer overflow in
On 21 Aug 2002, Rod Taylor wrote: Agreed. If patches are applied to the 7.4 branch as fast as normal, then maybe 7.4 will only be 6 months out with well tested Windows, PIT, etc. code that gets applied this October. Whats the intended branchpoint? Beta with less than 5 patches? 3rd beta start period? Less than 100 lines changed between betas? Actually, I believe the agreement on branchpoint for this release was release date ... with the normal having been a few weeks *after* release in previous releases ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
OK, beta starts on time, September 1. I agree we should keep the agreed-upon date, and that the propsed features aren't ready, but I had to let the discussion happen so people felt their opinions where being heard. --- Marc G. Fournier wrote: On Wed, 21 Aug 2002, Bruce Momjian wrote: Justin Clift wrote: Reckon it's worth asking him, to find out if he'd be interested in this? I wouldn't do it yet until we know if we are going to delay. Any security audit of the code should *not* be done while the code is in flux, and if we delay, the code would be in flux since the delay would be to throw in a load of other code that would invalidate the audit results ... Oh, so it is Jan's group. Great news; wish someone would have told me sooner. I removed the Win32 off the open items list because, with no info and no one commenting on the item, it seemed dead for 7.3. And it should be ... we can put the Win32 patches up on the ftp site for ppl to play with if they want, but to include it at this late a date would be irresponsible ... Well, PITR is a much more desired feature even than Win32; the big question is how long PITR will actually take, seeing as we haven't see any patches yet. However, we haven't seen any Win32 patches yet either, so they are in the same boat as far as I am concerned. We have an open items list that is pretty much ready for 7.3. The only open items of significance left is whether schema/DROP COLUMN stuff is ready in all the interfaces/apps. We set a timeline for beta ... this time, let's stick to it ... its not like we didn't advertise when we were going into beta ... hell, even when the patches are presented for PITR support, who knows whether they will be accepted, or what kinda bugs they are going to throw into the mix, or ... -- 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 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
Marc G. Fournier wrote: On 21 Aug 2002, Rod Taylor wrote: Agreed. If patches are applied to the 7.4 branch as fast as normal, then maybe 7.4 will only be 6 months out with well tested Windows, PIT, etc. code that gets applied this October. Whats the intended branchpoint? Beta with less than 5 patches? 3rd beta start period? Less than 100 lines changed between betas? Actually, I believe the agreement on branchpoint for this release was release date ... with the normal having been a few weeks *after* release in previous releases ... Actually, you proposed beta2 as the branch time for this release, and no one objected. I think we will have to be flexible and see how heavy the patching is during beta, but I think the latest would be on release date. Our releases are very solid now, so we have very little patching after release, and now that I and Tom are fulltime, we can handle the load of double-patching better. -- 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])
Branch Date (Was: Re: [HACKERS] @(#)Mordred Labs advisory 0...)
On Wed, 21 Aug 2002, Bruce Momjian wrote: Marc G. Fournier wrote: On 21 Aug 2002, Rod Taylor wrote: Agreed. If patches are applied to the 7.4 branch as fast as normal, then maybe 7.4 will only be 6 months out with well tested Windows, PIT, etc. code that gets applied this October. Whats the intended branchpoint? Beta with less than 5 patches? 3rd beta start period? Less than 100 lines changed between betas? Actually, I believe the agreement on branchpoint for this release was release date ... with the normal having been a few weeks *after* release in previous releases ... Actually, you proposed beta2 as the branch time for this release, and no one objected. I think we will have to be flexible and see how heavy the patching is during beta, but I think the latest would be on release date. Our releases are very solid now, so we have very little patching after release, and now that I and Tom are fulltime, we can handle the load of double-patching better. Oh, even better :) I didn't think I had succeeded in getting it brought *that* far forward :) ---(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
Let me see if I have my release dates straight: A 7.2.2 release in the next week or so that fixes the bugtraq buffer overflows and timestamp issues A 7.3 beta on Sept 1st that has all the new schema jazz and also the fixes for opaque (as well as other stuff from todo) during which time we get more security auditing Hopefully an official 7.3 release on October 1. 7.4/8.0 development will start and native windows and PITR patches can start being submitted for that? Robert Treat On Wed, 2002-08-21 at 14:06, Bruce Momjian wrote: OK, beta starts on time, September 1. I agree we should keep the agreed-upon date, and that the propsed features aren't ready, but I had to let the discussion happen so people felt their opinions where being heard. --- Marc G. Fournier wrote: On Wed, 21 Aug 2002, Bruce Momjian wrote: Justin Clift wrote: Reckon it's worth asking him, to find out if he'd be interested in this? I wouldn't do it yet until we know if we are going to delay. Any security audit of the code should *not* be done while the code is in flux, and if we delay, the code would be in flux since the delay would be to throw in a load of other code that would invalidate the audit results ... Oh, so it is Jan's group. Great news; wish someone would have told me sooner. I removed the Win32 off the open items list because, with no info and no one commenting on the item, it seemed dead for 7.3. And it should be ... we can put the Win32 patches up on the ftp site for ppl to play with if they want, but to include it at this late a date would be irresponsible ... Well, PITR is a much more desired feature even than Win32; the big question is how long PITR will actually take, seeing as we haven't see any patches yet. However, we haven't seen any Win32 patches yet either, so they are in the same boat as far as I am concerned. We have an open items list that is pretty much ready for 7.3. The only open items of significance left is whether schema/DROP COLUMN stuff is ready in all the interfaces/apps. We set a timeline for beta ... this time, let's stick to it ... its not like we didn't advertise when we were going into beta ... hell, even when the patches are presented for PITR support, who knows whether they will be accepted, or what kinda bugs they are going to throw into the mix, or ... -- 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 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Dev Cycles (Was: Re: [HACKERS] @(#)Mordred Labs advisory 0x...)
On 21 Aug 2002, Robert Treat wrote: Let me see if I have my release dates straight: A 7.2.2 release in the next week or so that fixes the bugtraq buffer overflows and timestamp issues A 7.3 beta on Sept 1st that has all the new schema jazz and also the fixes for opaque (as well as other stuff from todo) during which time we get more security auditing Hopefully an official 7.3 release on October 1. 7.4/8.0 development will start and native windows and PITR patches can start being submitted for that? Correct ... and, if all goes well, patches for the v7.4 branch should be acceptable sometime mid-Sept ... Robert Treat On Wed, 2002-08-21 at 14:06, Bruce Momjian wrote: OK, beta starts on time, September 1. I agree we should keep the agreed-upon date, and that the propsed features aren't ready, but I had to let the discussion happen so people felt their opinions where being heard. --- Marc G. Fournier wrote: On Wed, 21 Aug 2002, Bruce Momjian wrote: Justin Clift wrote: Reckon it's worth asking him, to find out if he'd be interested in this? I wouldn't do it yet until we know if we are going to delay. Any security audit of the code should *not* be done while the code is in flux, and if we delay, the code would be in flux since the delay would be to throw in a load of other code that would invalidate the audit results ... Oh, so it is Jan's group. Great news; wish someone would have told me sooner. I removed the Win32 off the open items list because, with no info and no one commenting on the item, it seemed dead for 7.3. And it should be ... we can put the Win32 patches up on the ftp site for ppl to play with if they want, but to include it at this late a date would be irresponsible ... Well, PITR is a much more desired feature even than Win32; the big question is how long PITR will actually take, seeing as we haven't see any patches yet. However, we haven't seen any Win32 patches yet either, so they are in the same boat as far as I am concerned. We have an open items list that is pretty much ready for 7.3. The only open items of significance left is whether schema/DROP COLUMN stuff is ready in all the interfaces/apps. We set a timeline for beta ... this time, let's stick to it ... its not like we didn't advertise when we were going into beta ... hell, even when the patches are presented for PITR support, who knows whether they will be accepted, or what kinda bugs they are going to throw into the mix, or ... -- 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 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 ---(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] CVS broken - large file support?
On FreeBSD/Alpha, CVS gives [trouble] I'm currently having to use configure --disable-largefile on HPUX; looks like you'll have to do the same until Peter finishes ironing out the wrinkles with autoconfiguring largefile support. It would be helpful if you'd poke into your system headers and find out (a) can you do large files at all, and if so (b) what is the correct magic combination of #defines for your system. FreeBSD 5.0-CURRENT, gcc 3.1 and 3.2 both have this same problem even with largefile disabled. Help? -sc gmake[4]: Leaving directory `/usr/home/sean/open_source/postgresql/pgsql/src/backend/parser' gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/interfaces/libpq -I../../../src/include -c -o pg_dump.o pg_dump.c gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/interfaces/libpq -I../../../src/include -c -o common.o common.c In file included from common.c:21: pg_backup_archiver.h:168: syntax error before off_t gmake[3]: *** [common.o] Error 1 gmake[3]: Leaving directory `/usr/home/sean/open_source/postgresql/pgsql/src/bin/pg_dump' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/home/sean/open_source/postgresql/pgsql/src/bin' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/home/sean/open_source/postgresql/pgsql/src' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/home/sean/open_source/postgresql/pgsql. -- Sean Chittenden ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Neil Conway [EMAIL PROTECTED] writes:
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:
No, no it does not :-)
Tom pointed out some obvious braindamage in my previous patch. I've
attached a revised version.
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.37
diff -c -r1.37 oracle_compat.c
*** src/backend/utils/adt/oracle_compat.c 8 Jan 2002 17:03:41 - 1.37
--- src/backend/utils/adt/oracle_compat.c 21 Aug 2002 21:03:59 -
***
*** 997,1002
--- 997,1012
slen = (VARSIZE(string) - VARHDRSZ);
tlen = (VARHDRSZ + (count * slen));
+ /* Check for integer overflow */
+ if (slen != 0 count != 0)
+ {
+ int check = count * slen;
+ int check2 = check + VARHDRSZ;
+
+ if ((check / slen) != count || check2 = check)
+ elog(ERROR, Requested buffer is too large.);
+ }
+
result = (text *) palloc(tlen);
VARATT_SIZEP(result) = tlen;
---(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
Tom Lane writes: 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. This is harmless (until proven otherwise). fseeko() is identical to fseek() except that the offset argument uses off_t, and _LARGEFILE_SOURCE makes fseeko() and friends visible in the headers. That's all. No large files involved. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [SECURITY] DoS attack on backend possible
[EMAIL PROTECTED] (Florian Weimer) wrote [EMAIL PROTECTED] writes: if you are going to be passing any user input to the database, you must/should validate in some manner before blindly passing it to the db. The db can and should guarantee data integrity, but the database cannot read your mind when it comes to how you structure your queries. [example of SQL injection attack deleted] This is not the problem at hand. SQL injection attacks can be avoided easily. Bugs in the conversion of strings to internal PostgreSQL objects are a different matter, though, and usually, devastating effects cannot be avoided by (reasonably complex) checks in the frontend. yeah i wasnt aware that adding a if(strlen($input) SOME_REASONABLE_MAX) was complex. the sql injection attack was just an(other) example of why you do not simply forward user input to the backend. all i was trying to point out is that most of these buffer overflows in the backend can be avoided just as easily as the sql injection attack. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Large file support available
Tom Lane writes:
/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.
You're supposed to define _LARGEFILE64_SOURCE if you want to use functions
like open64(), fseek64(), getrlimit64(), etc. in your source. We don't
want those, obviously.
What is happening here is that evidently the system headers effectively
redefine getrlimit() to point to getrlimit64() if FILE_OFFSET_BITS=64,
which is the usual strategy for all the I/O functions. But you're not
supposed to have to define _LARGEFILE64_SOURCE for this, because the
change is supposed to be transparent.
If the {s|g}etrlimit warnings are indeed the only ones (i.e., none about
open, fseek, write, read, etc.) then this is either a bug or there's
something wrong in the include file order or something like that. Which
way is sys/resource.h included anyway?
If there's no way to fix it then we can add a definition of
_LARGEFILE64_SOURCE to hpux.h and consider further action.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] bison news
Bruce Momjian writes: 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. I imagine that bison doesn't get a lot of beta testing, since people don't have a whole bunch of production grammars lying around that they want to upgrade at the earliest possible moment. So if we want to test it more, we could propagate it to our beta testers. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Trouble debugging contrib/fulltextindex
Christopher Kings-Lynne writes: 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. First, compile without optimization (-O0). Second, using LOAD to load the shared object before the function call may be of advantage. I would allow you to set breakpoints in the loaded object, for example. Just waiting for the code to crash and hoping to get a good backtrace isn't always a successful strategy. 2. Should contribs exclusively use palloc/pfree? Yes (unless there are some wildly unusual memory allocation requirements). -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Build failure in current CVS
Tatsuo Ishii writes: 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? The following patch works, it just needs to be extrapolated to the other directories. diff -ru cvs-pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic/Makefile pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic/Makefile --- cvs-pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic/Makefile Wed Aug 14 04:45:10 2002 +++ pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic/Makefile Wed Aug 21 +21:22:47 2002 @@ -3,9 +3,10 @@ # $Id: Makefile,v 1.1 2002/08/14 02:45:10 ishii Exp $ # #- +subdir = src/backend/utils/mb/conversion_procs/ascii_and_mic top_builddir = ../../../../../.. include $(top_builddir)/src/Makefile.global NAME := ascii_and_mic -include ../proc.mk +include $(srcdir)/../proc.mk diff -ru cvs-pgsql/src/backend/utils/mb/conversion_procs/proc.mk pgsql/src/backend/utils/mb/conversion_procs/proc.mk --- cvs-pgsql/src/backend/utils/mb/conversion_procs/proc.mk Sat Aug 10 00:53:26 2002 +++ pgsql/src/backend/utils/mb/conversion_procs/proc.mk Wed Aug 21 21:12:29 2002 @@ -16,6 +16,6 @@ clean distclean maintainer-clean: clean-lib $(RM) $(OBJS) -include $(top_builddir)/src/Makefile.shlib +include $(top_srcdir)/src/Makefile.shlib all: $(shlib) ===end -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] CREATE CAST WITHOUT FUNCTION should require superuserness?
Tom Lane writes: 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. Feel free. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in
Yep, that's the plan! --- Robert Treat wrote: Let me see if I have my release dates straight: A 7.2.2 release in the next week or so that fixes the bugtraq buffer overflows and timestamp issues A 7.3 beta on Sept 1st that has all the new schema jazz and also the fixes for opaque (as well as other stuff from todo) during which time we get more security auditing Hopefully an official 7.3 release on October 1. 7.4/8.0 development will start and native windows and PITR patches can start being submitted for that? Robert Treat On Wed, 2002-08-21 at 14:06, Bruce Momjian wrote: OK, beta starts on time, September 1. I agree we should keep the agreed-upon date, and that the propsed features aren't ready, but I had to let the discussion happen so people felt their opinions where being heard. --- Marc G. Fournier wrote: On Wed, 21 Aug 2002, Bruce Momjian wrote: Justin Clift wrote: Reckon it's worth asking him, to find out if he'd be interested in this? I wouldn't do it yet until we know if we are going to delay. Any security audit of the code should *not* be done while the code is in flux, and if we delay, the code would be in flux since the delay would be to throw in a load of other code that would invalidate the audit results ... Oh, so it is Jan's group. Great news; wish someone would have told me sooner. I removed the Win32 off the open items list because, with no info and no one commenting on the item, it seemed dead for 7.3. And it should be ... we can put the Win32 patches up on the ftp site for ppl to play with if they want, but to include it at this late a date would be irresponsible ... Well, PITR is a much more desired feature even than Win32; the big question is how long PITR will actually take, seeing as we haven't see any patches yet. However, we haven't seen any Win32 patches yet either, so they are in the same boat as far as I am concerned. We have an open items list that is pretty much ready for 7.3. The only open items of significance left is whether schema/DROP COLUMN stuff is ready in all the interfaces/apps. We set a timeline for beta ... this time, let's stick to it ... its not like we didn't advertise when we were going into beta ... hell, even when the patches are presented for PITR support, who knows whether they will be accepted, or what kinda bugs they are going to throw into the mix, or ... -- 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 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 -- 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] Large file support available
Peter Eisentraut wrote: Tom Lane writes: 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. This is harmless (until proven otherwise). fseeko() is identical to fseek() except that the offset argument uses off_t, and _LARGEFILE_SOURCE makes fseeko() and friends visible in the headers. That's all. No large files involved. I am confused. fseeko() doesn't look standard to me. I though fgetpos/fsetpos() where the standard interfaces for large file support; from BSD/OS: The fgetpos(), fsetpos(), fseek(), ftell(), and rewind() functions con- form to ANSI C X3.159-1989 (``ANSI C ''). -- 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] Build failure in current CVS
OK, patch applied to all Makefiles, as outlined by Peter. --- Peter Eisentraut wrote: Tatsuo Ishii writes: 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? The following patch works, it just needs to be extrapolated to the other directories. diff -ru cvs-pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic/Makefile pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic/Makefile --- cvs-pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic/MakefileWed Aug 14 04:45:10 2002 +++ pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic/MakefileWed Aug 21 21:22:47 2002 @@ -3,9 +3,10 @@ # $Id: Makefile,v 1.1 2002/08/14 02:45:10 ishii Exp $ # #- +subdir = src/backend/utils/mb/conversion_procs/ascii_and_mic top_builddir = ../../../../../.. include $(top_builddir)/src/Makefile.global NAME := ascii_and_mic -include ../proc.mk +include $(srcdir)/../proc.mk diff -ru cvs-pgsql/src/backend/utils/mb/conversion_procs/proc.mk pgsql/src/backend/utils/mb/conversion_procs/proc.mk --- cvs-pgsql/src/backend/utils/mb/conversion_procs/proc.mk Sat Aug 10 00:53:26 2002 +++ pgsql/src/backend/utils/mb/conversion_procs/proc.mk Wed Aug 21 21:12:29 2002 @@ -16,6 +16,6 @@ clean distclean maintainer-clean: clean-lib $(RM) $(OBJS) -include $(top_builddir)/src/Makefile.shlib +include $(top_srcdir)/src/Makefile.shlib all: $(shlib) ===end -- Peter Eisentraut [EMAIL PROTECTED] ---(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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] CVS broken - large file support?
On FreeBSD/Alpha, CVS gives [trouble] I'm currently having to use configure --disable-largefile on HPUX; looks like you'll have to do the same until Peter finishes ironing out the wrinkles with autoconfiguring largefile support. It would be helpful if you'd poke into your system headers and find out (a) can you do large files at all, and if so (b) what is the correct magic combination of #defines for your system. FreeBSD 5.0-CURRENT, gcc 3.1 and 3.2 both have this same problem even with largefile disabled. Help? -sc For those interested and with commit powers, including sys/types.h in pg_backup_archiver.h fixes this build problem. -sc gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/interfaces/libpq -I../../../src/include -c -o common.o common.c In file included from common.c:21: pg_backup_archiver.h:168: syntax error before off_t gmake[3]: *** [common.o] Error 1 -- Sean Chittenden Index: pg_backup_archiver.h === RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/pg_backup_archiver.h,v retrieving revision 1.46 diff -u -r1.46 pg_backup_archiver.h --- pg_backup_archiver.h2002/08/20 17:54:44 1.46 +++ pg_backup_archiver.h2002/08/21 23:01:14 @@ -29,6 +29,7 @@ #include time.h #include errno.h +#include sys/types.h #include pqexpbuffer.h #define LOBBUFSIZE 32768 ---(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
Bruce Momjian [EMAIL PROTECTED] writes: OK, patch applied to all Makefiles, as outlined by Peter. I see this in current CVS: make[3]: Entering directory `/home/nconway/pgsql/src/backend/utils/mb/conversion_procs' make[4]: Entering directory `/home/nconway/pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic' Makefile:1: *** missing separator. Stop. make[4]: Leaving directory `/home/nconway/pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic' make[3]: *** [all] Error 2 Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] libpq++ and libpqxx moved to GBorg ...
Morning all ... This afternoon, Bruce Momjiam created a new project on GBorg for libpq++, and Jeroen T. Vermeulen created one for libpqxx ... Both projects source directory from the central CVS repository have been copied over, including full history logs, and can be viewed at: libpqxx: http://gborg.postgresql.org/project/libpqxx/projdisplay.php And libpq++: http://gborg.postgresql.org/project/libpqpp/projdisplay.php Let us know of any problems with either project ... ---(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] libpq++ and libpqxx removed
they are no longer on the central repository, but are on GBorg ... I've made the appropriate chagnes to configure and Makefiles to reflect the fact that libpq++ is no longer part of the central distribution, *but* I used 'cvs remove' to remove the files themselves, so that the old branches (ie. if we do a v7.2.2, we need it) still have access to the code ... let me know if there are any problems ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] libpq++ documentation ...
That's one thing that I can't touch, since I have no idea about SGML :( Bruce, can you extract that and add it to the CVS repository for libpq++? ---(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
On Wed, 21 Aug 2002, Gavin Sherry wrote: On Tue, 20 Aug 2002, Thomas Lockhart wrote: ... 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. Just a minor point: can someone actually show a symptom with date/time problems in 7.2.x? [snip] server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. !# ParseDateTime() isn't checking that str MAXDATELEN -- which is the problem you solved in the datetime.c fixes. I had a look at this code on the train. There does not appear to be any way on conventional hardware manipulate this bug to smash the stack. This is due to the fact that ParseDateTime() returns to the caller if it encounters a non-printable character. It would be perhaps one of the most impressive hacks ever if someone could dream machine code to put in the overrun which consisted entirely of printable characters. As such, it is remarkably unlikely that someone could exploit this bug to execute arbitary code. Gavin ---(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 0x0003: Buffer overflow in
If we are going to delay beta, we should decide now, not at the end of August, and the delay should be until the end of September. The big question is whether we have enough material to warrant a delay. Beta goes down in 1 week ... if we follow what we had talked about before, within a short period of time after beta, we should be able to let ppl dive into working on v7.4 (or 8.0, whatever we decide to call it) ... but let's try and stick to a timeline for once, else we are going to hit the same as the last *very* extended release ... I'd much rather see 7.3 as-is then an 8.0 not so later on with win32 native and PITR _properly_tested_. Chris ---(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] libpq++ and libpqxx removed
Can we perhaps have very prominent linking to gborg from the postgresql.org home page? Especially now that there's libpq++ and stuff on there? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Marc G. Fournier Sent: Thursday, 22 August 2002 8:21 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [HACKERS] libpq++ and libpqxx removed they are no longer on the central repository, but are on GBorg ... I've made the appropriate chagnes to configure and Makefiles to reflect the fact that libpq++ is no longer part of the central distribution, *but* I used 'cvs remove' to remove the files themselves, so that the old branches (ie. if we do a v7.2.2, we need it) still have access to the code ... let me know if there are any problems ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] libpq++ and libpqxx removed
There will be on the new portal, but you are right, we should have such on the current one until the new portal is in place ... Vince, can you add a link to it off the menus themselves on the left side? On Thu, 22 Aug 2002, Christopher Kings-Lynne wrote: Can we perhaps have very prominent linking to gborg from the postgresql.org home page? Especially now that there's libpq++ and stuff on there? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Marc G. Fournier Sent: Thursday, 22 August 2002 8:21 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [HACKERS] libpq++ and libpqxx removed they are no longer on the central repository, but are on GBorg ... I've made the appropriate chagnes to configure and Makefiles to reflect the fact that libpq++ is no longer part of the central distribution, *but* I used 'cvs remove' to remove the files themselves, so that the old branches (ie. if we do a v7.2.2, we need it) still have access to the code ... let me know if there are any problems ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Build failure in current CVS
I get the same - FreeBSD/Alpha. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Neil Conway Sent: Thursday, 22 August 2002 7:13 AM To: Bruce Momjian Cc: Peter Eisentraut; Tatsuo Ishii; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [HACKERS] Build failure in current CVS Bruce Momjian [EMAIL PROTECTED] writes: OK, patch applied to all Makefiles, as outlined by Peter. I see this in current CVS: make[3]: Entering directory `/home/nconway/pgsql/src/backend/utils/mb/conversion_procs' make[4]: Entering directory `/home/nconway/pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic' Makefile:1: *** missing separator. Stop. make[4]: Leaving directory `/home/nconway/pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic' make[3]: *** [all] Error 2 Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] CVS broken - large file support?
On FreeBSD/Alpha, CVS gives [trouble] I'm currently having to use configure --disable-largefile on HPUX; looks like you'll have to do the same until Peter finishes ironing out the wrinkles with autoconfiguring largefile support. It would be helpful if you'd poke into your system headers and find out (a) can you do large files at all, and if so (b) what is the correct magic combination of #defines for your system. FreeBSD 5.0-CURRENT, gcc 3.1 and 3.2 both have this same problem even with largefile disabled. Help? -sc For those interested and with commit powers, including sys/types.h in pg_backup_archiver.h fixes this build problem. -sc gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/interfaces/libpq -I../../../src/include -c -o common.o common.c In file included from common.c:21: pg_backup_archiver.h:168: syntax error before off_t gmake[3]: *** [common.o] Error 1 'nother trivial type-o/patch that gets building working with --disable-largefile. -sc -- Sean Chittenden Index: src/backend/utils/mb/conversion_procs/ascii_and_mic/Makefile === RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/mb/conversion_procs/ascii_and_mic/Makefile,v retrieving revision 1.2 diff -u -r1.2 Makefile --- src/backend/utils/mb/conversion_procs/ascii_and_mic/Makefile2002/08/21 21:33:55 1.2 +++ src/backend/utils/mb/conversion_procs/ascii_and_mic/Makefile2002/08/22 +02:10:28 @@ -1,4 +1,4 @@ -]#- +#- # # $Id: Makefile,v 1.2 2002/08/21 21:33:55 momjian Exp $ # ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Build failure in current CVS
Thanks. Fixed. I had a '[' on the first line of one of the makefiles. --- Neil Conway wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, patch applied to all Makefiles, as outlined by Peter. I see this in current CVS: make[3]: Entering directory `/home/nconway/pgsql/src/backend/utils/mb/conversion_procs' make[4]: Entering directory `/home/nconway/pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic' Makefile:1: *** missing separator. Stop. make[4]: Leaving directory `/home/nconway/pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic' make[3]: *** [all] Error 2 Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere 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] libpq++ and libpqxx removed
On Wed, 21 Aug 2002, Marc G. Fournier wrote: There will be on the new portal, but you are right, we should have such on the current one until the new portal is in place ... Vince, can you add a link to it off the menus themselves on the left side? Sure. Make me a button that matches the rest. That's what the holdup has been for any changes. That's why I've been soliciting new designs. The new portal isn't going to help in this regard either, I've been trying to tell you that for months. On Thu, 22 Aug 2002, Christopher Kings-Lynne wrote: Can we perhaps have very prominent linking to gborg from the postgresql.org home page? Especially now that there's libpq++ and stuff on there? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Marc G. Fournier Sent: Thursday, 22 August 2002 8:21 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [HACKERS] libpq++ and libpqxx removed they are no longer on the central repository, but are on GBorg ... I've made the appropriate chagnes to configure and Makefiles to reflect the fact that libpq++ is no longer part of the central distribution, *but* I used 'cvs remove' to remove the files themselves, so that the old branches (ie. if we do a v7.2.2, we need it) still have access to the code ... let me know if there are any problems ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] libpq++ documentation ...
I can remove it cleanly, but I have no idea how to add the SGML in a way that will allow it to build. --- Marc G. Fournier wrote: That's one thing that I can't touch, since I have no idea about SGML :( Bruce, can you extract that and add it to the CVS repository for libpq++? ---(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 -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] libpq++ and libpqxx removed
Where can we see the new portal? Maybe it should be designed in such a way as to not use image links at all. From all my experience in doing websites - that'd be a _really_ good idea. Chris There will be on the new portal, but you are right, we should have such on the current one until the new portal is in place ... Vince, can you add a link to it off the menus themselves on the left side? Sure. Make me a button that matches the rest. That's what the holdup has been for any changes. That's why I've been soliciting new designs. The new portal isn't going to help in this regard either, I've been trying to tell you that for months. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CVS broken - large file support?
Yea, that was my booboo, fixed now. --- Sean Chittenden wrote: On FreeBSD/Alpha, CVS gives [trouble] I'm currently having to use configure --disable-largefile on HPUX; looks like you'll have to do the same until Peter finishes ironing out the wrinkles with autoconfiguring largefile support. It would be helpful if you'd poke into your system headers and find out (a) can you do large files at all, and if so (b) what is the correct magic combination of #defines for your system. FreeBSD 5.0-CURRENT, gcc 3.1 and 3.2 both have this same problem even with largefile disabled. Help? -sc For those interested and with commit powers, including sys/types.h in pg_backup_archiver.h fixes this build problem. -sc gcc -pipe -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/interfaces/libpq -I../../../src/include -c -o common.o common.c In file included from common.c:21: pg_backup_archiver.h:168: syntax error before off_t gmake[3]: *** [common.o] Error 1 'nother trivial type-o/patch that gets building working with --disable-largefile. -sc -- Sean Chittenden [ Attachment, skipping... ] ---(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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] libpq++ and libpqxx removed
On Thu, 22 Aug 2002, Christopher Kings-Lynne wrote: Where can we see the new portal? Maybe it should be designed in such a way as to not use image links at all. From all my experience in doing websites - that'd be a _really_ good idea. I don't believe we are using image links on the new portal ... Chris There will be on the new portal, but you are right, we should have such on the current one until the new portal is in place ... Vince, can you add a link to it off the menus themselves on the left side? Sure. Make me a button that matches the rest. That's what the holdup has been for any changes. That's why I've been soliciting new designs. The new portal isn't going to help in this regard either, I've been trying to tell you that for months. ---(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] libpq++ documentation ...
On Wed, 21 Aug 2002, Bruce Momjian wrote: I can remove it cleanly, but I have no idea how to add the SGML in a way that will allow it to build. Anyone with some time on their hands that knows SGML enough to do this? :) For now, can you extract what is required and commit it to the project *but* don't remove from our central source(s)? Maybe add a prominent comment in the docs for now that the source has moved to GBorg, so that ppl aren't confused that the docs are there but there is no code, until we can get a 'clean build' of the docs in the project itself? --- Marc G. Fournier wrote: That's one thing that I can't touch, since I have no idea about SGML :( Bruce, can you extract that and add it to the CVS repository for libpq++? ---(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 -- 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] Build failure in current CVS
I appreciate you and other guys who has been working for this problem. -- Tatsuo Ishii Thanks. Fixed. I had a '[' on the first line of one of the makefiles. --- Neil Conway wrote: Bruce Momjian [EMAIL PROTECTED] writes: OK, patch applied to all Makefiles, as outlined by Peter. I see this in current CVS: make[3]: Entering directory `/home/nconway/pgsql/src/backend/utils/mb/conversion_procs' make[4]: Entering directory `/home/nconway/pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic' Makefile:1: *** missing separator. Stop. make[4]: Leaving directory `/home/nconway/pgsql/src/backend/utils/mb/conversion_procs/ascii_and_mic' make[3]: *** [all] Error 2 Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere 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
[HACKERS] Theoretical XML ltree Question
Hi, ltree is good and fast at indexing hierarchies, right? XML is a standard way of storing hierarchies, right? Would there be any way of allowing ltree to index XML text fields to allow really fast XPath searches? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] libpq++ documentation ...
I will remove it from our cvs and move it over, and clean up our SGML to compile properly. I can do that much. --- Marc G. Fournier wrote: On Wed, 21 Aug 2002, Bruce Momjian wrote: I can remove it cleanly, but I have no idea how to add the SGML in a way that will allow it to build. Anyone with some time on their hands that knows SGML enough to do this? :) For now, can you extract what is required and commit it to the project *but* don't remove from our central source(s)? Maybe add a prominent comment in the docs for now that the source has moved to GBorg, so that ppl aren't confused that the docs are there but there is no code, until we can get a 'clean build' of the docs in the project itself? --- Marc G. Fournier wrote: That's one thing that I can't touch, since I have no idea about SGML :( Bruce, can you extract that and add it to the CVS repository for libpq++? ---(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 -- 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 -- 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] libpq++ documentation ...
Done. --- Bruce Momjian wrote: I will remove it from our cvs and move it over, and clean up our SGML to compile properly. I can do that much. --- Marc G. Fournier wrote: On Wed, 21 Aug 2002, Bruce Momjian wrote: I can remove it cleanly, but I have no idea how to add the SGML in a way that will allow it to build. Anyone with some time on their hands that knows SGML enough to do this? :) For now, can you extract what is required and commit it to the project *but* don't remove from our central source(s)? Maybe add a prominent comment in the docs for now that the source has moved to GBorg, so that ppl aren't confused that the docs are there but there is no code, until we can get a 'clean build' of the docs in the project itself? --- Marc G. Fournier wrote: That's one thing that I can't touch, since I have no idea about SGML :( Bruce, can you extract that and add it to the CVS repository for libpq++? ---(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 -- 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 -- 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 -- 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] libpq++ documentation ...
I knew that was coming. Some have been concerned that though Edmund said OK, there is some new person who is the maintainer, though you would think Edmund would be the final word on that. Anyway, I will do it now, or as soon as I empty the patch queue. --- Marc G. Fournier wrote: 'K, wanna do DBD::Pg next? :) On Wed, 21 Aug 2002, Bruce Momjian wrote: Done. --- Bruce Momjian wrote: I will remove it from our cvs and move it over, and clean up our SGML to compile properly. I can do that much. --- Marc G. Fournier wrote: On Wed, 21 Aug 2002, Bruce Momjian wrote: I can remove it cleanly, but I have no idea how to add the SGML in a way that will allow it to build. Anyone with some time on their hands that knows SGML enough to do this? :) For now, can you extract what is required and commit it to the project *but* don't remove from our central source(s)? Maybe add a prominent comment in the docs for now that the source has moved to GBorg, so that ppl aren't confused that the docs are there but there is no code, until we can get a 'clean build' of the docs in the project itself? --- Marc G. Fournier wrote: That's one thing that I can't touch, since I have no idea about SGML :( Bruce, can you extract that and add it to the CVS repository for libpq++? ---(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 -- 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 -- 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 -- 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 -- 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] libpq++ documentation ...
On Wed, 21 Aug 2002, Bruce Momjian wrote: I knew that was coming. Some have been concerned that though Edmund said OK, there is some new person who is the maintainer, though you would think Edmund would be the final word on that. Anyway, I will do it now, or as soon as I empty the patch queue. IMHO, if there is someone else, they should be step'ng forward to let us know, no? ---(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
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes: Ok, now I vote, that you don't implement any and use opaque. I don't think we want two types that do the same thing. Is it that you like the name any more than opaque ? No, it's that I want to deprecate opaque so that we can catch old uses that should not be there anymore. If you look at your code and you decide that any is the correct semantics, then fine: change opaque to any and the warnings will go away. But relatively few existing uses of opaque really mean any, and I don't want the people who are using opaque to mean cstring, trigger, etc to keep using opaque for those other purposes. The idea here is to force a security review. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#)Mordred Labs advisory 0x0002: Buffer overflow in PostgreSQL
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: The handling of the TZ environmental variable is subject to a buffer overrun. This problem is long gone in current sources, no? The patch looks like it does prevent some problems. -- 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 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] libpq++ documentation ...
Yep, let's create the project. --- Marc G. Fournier wrote: On Wed, 21 Aug 2002, Bruce Momjian wrote: I knew that was coming. Some have been concerned that though Edmund said OK, there is some new person who is the maintainer, though you would think Edmund would be the final word on that. Anyway, I will do it now, or as soon as I empty the patch queue. IMHO, if there is someone else, they should be step'ng forward to let us know, no? -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL
Patch applied. Thanks. --- Neil Conway wrote: 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 [ Attachment, skipping... ] ---(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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows
Patch applied. Thanks.
---
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.)
Cheers,
Neil
--
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
--
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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Large file support available
Peter Eisentraut [EMAIL PROTECTED] writes:
If the {s|g}etrlimit warnings are indeed the only ones (i.e., none about
open, fseek, write, read, etc.) then this is either a bug or there's
something wrong in the include file order or something like that.
No such luck. Here's a more complete excerpt of one typical failure:
gcc -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -I../../../../src/include
-c -o tuptoaster.o tuptoaster.c
In file included from /usr/include/sys/wait.h:83,
from
/usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.3/include/stdlib.h:231,
from ../../../../src/include/c.h:56,
from ../../../../src/include/postgres.h:47,
from tuptoaster.c:25:
/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'
In file included from /usr/include/unistd.h:11,
from tuptoaster.c:27:
/usr/include/sys/unistd.h: In function `truncate':
/usr/include/sys/unistd.h:539: warning: implicit declaration of function `__truncate64'
/usr/include/sys/unistd.h: In function `prealloc':
/usr/include/sys/unistd.h:543: warning: implicit declaration of function `__prealloc64'
/usr/include/sys/unistd.h: In function `lockf':
/usr/include/sys/unistd.h:544: warning: implicit declaration of function `__lockf64'
/usr/include/sys/unistd.h: In function `ftruncate':
/usr/include/sys/unistd.h:545: warning: implicit declaration of function
`__ftruncate64'
In file included from /usr/include/fcntl.h:9,
from tuptoaster.c:28:
/usr/include/sys/fcntl.h: In function `open':
/usr/include/sys/fcntl.h:216: warning: implicit declaration of function `__open64'
/usr/include/sys/fcntl.h: In function `creat':
/usr/include/sys/fcntl.h:217: warning: implicit declaration of function `__creat64'
AFAICT a *lot* of HPUX headers expect you to #define _LARGEFILE64_SOURCE
if you want this stuff to work.
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
