Re: [BUGS] BUG #1151: Initdb fails ...
--- Tom Lane <[EMAIL PROTECTED]> a écrit : > > Hm. It's starting to sound like an actual bug --- > though whether it's > in HPUX 11.00, gcc, or Postgres is difficult to > guess. Arg :-( > The Postgres > code is certainly known to work on many platforms, > but it could have > an unsuspected platform dependency that only shows > up here. Sure. > One thing I'd ask is whether you are up-to-date on > libc patches for your > HPUX installation. It's plausible that this could > be the result of > buggy libc code (such as strtol or related > routines). I'll check this point. > And my > recollection is that 11.00 was about as bulletproof > as you'd expect for > a dot-zero release :-( Unfortunatly, this machine is too old and leak of disk space to upgrade it to 11i (Cost reduction rulez ! :-((( ). > If no joy there, the only thing I can suggest is to > rebuild with > --enable-debug (if you didn't already) and start > digging into it with > gdb. If that sounds a bit out of your league, I'd > be willing to do it > if you can give me ssh access to the machine. (I > don't need root, > an unprivileged user account is enough.) Unfortunatly, it's not possible as this machine is behind our companie firewall. I'll let you know. Regards, Laurent = The misspelling master is on the Web. _100 % Dictionnary Free ! //( / Dico / / Pleins d'autres fautes sur // /http://go.to/destroyedlolo (###( / http://destroyedlolo.homeunix.org:8080 Quoi, des fautes d'orthographe! Pas possible ;-D. Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez Yahoo! Messenger sur http://fr.messenger.yahoo.com ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Fix for buffer overflow ready [was: Fwd: Bug#247306: odbc-postgresql: SIGSEGV with long inputs (> 10000 bytes)]
Martin Pitt wrote: > The problem is that make_string() in misc.c does not check whether > the target buffer is big enough to hold the copied string. > > I added a bufsize parameter to make_string() and used it in all calls > to it. I tried it with my php4 crash test script and now it works > properly. Silently truncating various pieces of information is probably not the right thing. What are you truncating? If it's a query string you might open yourself up to SQL-injection type problems. Plus, the ODBC driver appears to have buffer overruns all over the place. We need to replace every instance of strcpy, strcat, sprintf, make_string, and the various other feeble attempts with pqexpbuffer from libpq. That's the only way to solve this problem once and for all. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] BUG #1150: grant options not properly checked
Tom Lane wrote: > After that, you get to the General Rules, which pretty clearly say > that trying to grant privileges you don't have grant option for is > just a warning and not an error condition. (Such privileges will not > be in the set of "identified privilege descriptors".) > > AFAICS the specification for REVOKE is exactly parallel. > > So the existing code is still wrong, but not in quite the way we > thought. > > I'd be the first to say that this aspect of the spec is a tad > bizarre. Does anyone want to argue for ignoring the spec and > implementing "saner" behavior? It's not like we are super close to > spec compliance for privileges otherwise ... My experience is that violating the spec in this area just leads to other problems. Does anyone know what IBM and Oracle do here? AFAICT, they're the ones writing the specs. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] Fix for buffer overflow ready [was: Fwd: Bug#247306: odbc-postgresql: SIGSEGV with long inputs (> 10000 bytes)]
Hi! On 2004-05-13 19:43 +0200, Peter Eisentraut wrote: > Silently truncating various pieces of information is probably not the > right thing. But IMHO still better than overwriting arbitrary other data and code. If an user supplies bogus input, he cannot expect to get something sane out. > What are you truncating? By now: - DSN, username, password, and the whole connection string; - table names in info.c: make_string(szTableName, cbTableName, pktab, sizeof(pktab)); - Two calls in info.c: make_string(szPkTableName, cbPkTableName, pk_table_needed, sizeof(pk_table_needed)); make_string(szFkTableName, cbFkTableName, fk_table_needed, sizeof(fk_table_needed)); If these values should not be truncated, then psqlodbc should not use fixed buffer sizes. Currently truncating them is way more sane than letting them mess up the whole memory. > If it's a query string you might open yourself up to SQL-injection > type problems. I don't think that the patch affects whole query strings, but of course I may be wrong. The point of this patch was to fix the most apparent overflows with least possible changes, and after a week of silence on the lists I just had to do something about it. And now at least the connection and exec methods seem to work safely. > Plus, the ODBC driver appears to have buffer overruns all over the > place. We need to replace every instance of strcpy, strcat, sprintf, > make_string, and the various other feeble attempts with pqexpbuffer > from libpq. That's the only way to solve this problem once and for > all. I would be glad if the next psqlodbc version would be written in a sane way, without fixed string lengths and with a clear and safe string "class" interface. But doing this is far beyond the scope of a security patch (especially for Debian stable). One question: which mailing list is the better place to discuss this? -odbc or -bugs? Thanks and have a nice day! Martin -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
