Thread: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
//@(#) Mordred Labs advisory 0x0007
Release data: 26/08/02
Name: Remote DoS condition in PostgreSQL
Versions affected: all versions
Conditions: entry in a pg_hba.conf file that matches attacker's host.
Risk: average
---[ Description:
Upon connecting to a database, postmaster will fork a new process.
After that, a child process will call a
src/backend/postmaster/postmaster.c:DoBackend() routine,
which after processing a startup packet (see src/include/libpq/pqcomm.h),
will invoke a src/backend/libpq/auth.c:ClientAuthentication() routine to
perform client authentication.
If there is an entry in pg_hba.conf file, that matches an attacker's host,
an attacker could trigger
invocation of src/backend/libpq/auth.c:recv_and_check_password0(), which
fails to detect a DoS condition.
---[ Details:
Consider this snip of code from src/backend/libpq/auth.c:
[snip]
static int recv_and_check_password0(Port *port) {int32 len;char *buf;if (pq_getint(&len, 4) == EOF) return
STATUS_EOF;len-= 4;buf = palloc(len); /* len is taken from a packet */
[snip]
Note, that the size of palloced memory is taken from the user's input,
which is stupid if you ask me.
--[ How to reproduce:
I dont want to provide any tools to illustrate this vulnerability.
--[ Solution
Disable network access for untrusted users.
________________________________________________________________________
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
On 26 Aug 2002 at 14:46, Sir Mordred The Traitor wrote:
> [snip]
> static int recv_and_check_password0(Port *port) {
> int32 len;
> char *buf;
>
> if (pq_getint(&len, 4) == EOF)
> return STATUS_EOF;
> len -= 4;
> buf = palloc(len); /* len is taken from a packet */
> [snip]
So that should read,
buf=palloc((len>LENMAX?SAFELEN:len));
is what you want to say?
sounds good to me.. But if it is taken from the packet, won't that be tripped
to MTA size? Just a naïve question. Never saw much of postgres code myself..
ByeShridhar
--
Wilcox's Law: A pat on the back is only a few centimeters from a kick in the
pants.
Sir Mordred The Traitor <mordred@s-mail.com> writes:
> Note, that the size of palloced memory is taken from the user's input,
> which is stupid if you ask me.
Beyond causing an "out of memory" error during the handshake, I fail to
see how there can be any problem. palloc is considerably more robust
than malloc.
> I dont want to provide any tools to illustrate this vulnerability.
Perhaps you haven't tried.
It may indeed make sense to put a range check here, but I'm getting
tired of hearing the words "dos attack" applied to conditions that
cannot be exploited to cause any real problem. All you are
accomplishing is to spread FUD among people who aren't sufficiently
familiar with the code to evaluate the seriousness of problems...
regards, tom lane
On Monday 26 August 2002 10:46 am, Sir Mordred The Traitor wrote: > Conditions: entry in a pg_hba.conf file that matches attacker's host. > Risk: average > --[ Solution > > Disable network access for untrusted users. TCP/IP access must be enabled as well. TCP/IP accessibility is OFF by default. I for one thought that it was normal operating procedure to only allow access to trusted machines; maybe I'm odd in that regard. Hey, if I can connect to postmaster I can DoS it quite easily, but flooding it with connection requests..... But, if we can thwart this, all the better. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
The point is really simple. Allocate a huge chunk of memory (no sense to cause out of memory error, as palloc will bail is a requested size > 1 gb). The postgres will be ready to suck your input, via pg_getbytes(), now in a loop send junk to postgresql. Of course you can fork a number of processes to improve your effect. The issues is that postgres allocate a chunk of memory and reads data, using an user's input, which has not completed authentication. This is badly anyway. Of course i tried, and wrote proggy for that, but i can repeat, i dont want to provide it here. >Sir Mordred The Traitor <mordred@s-mail.com> writes: >> Note, that the size of palloced memory is taken from the user's input, >> which is stupid if you ask me. > >Beyond causing an "out of memory" error during the handshake, I fail to >see how there can be any problem. palloc is considerably more robust >than malloc. > >> I dont want to provide any tools to illustrate this vulnerability. > >Perhaps you haven't tried. > >It may indeed make sense to put a range check here, but I'm getting >tired of hearing the words "dos attack" applied to conditions that >cannot be exploited to cause any real problem. All you are >accomplishing is to spread FUD among people who aren't sufficiently >familiar with the code to evaluate the seriousness of problems... > > regards, tom lane > >---------------------------(end of broadcast)--------------------------- >TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > ________________________________________________________________________ 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
-*- Lamar Owen <lamar.owen@wgcr.org> [ 2002-08-26 15:19 ]: > TCP/IP access must be enabled as well. TCP/IP accessibility is OFF by > default. > > I for one thought that it was normal operating procedure to only allow access > to trusted machines; maybe I'm odd in that regard. > > Hey, if I can connect to postmaster I can DoS it quite easily, but flooding it > with connection requests..... > > But, if we can thwart this, all the better. Well, ISP's that offer webhosting and database connectivity might also be running a PostgreSQL server that only allows connectionsfrom that specific webserver (TCP port 5432 access not blocked as well as an pg_hba.conf entry). Now, if a userwith access to the webserver has privileges to open a socket connection, he could exploit this. -- Regards, Tolli tolli@tol.li
>Hey, if I can connect to postmaster I can DoS it quite easily, but flooding it >with connection requests..... Hm, that's true of course, but now i will do this with a couple of connections. Lets say, bot on a owned machine, connects to a database, send a crafted packet, postgresql will allocate a huge amount of memory, and will be happy to read anything it recvs from my bot. ________________________________________________________________________ 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
so basically if you are an idiot admin, and leave the postgresql box open (explicitly opening stuff), and under certian conditions, you can get DoS'd? hrm, this may not be your biggest problem. maybe if the dba has a clue and only explicitly allows certian ips to even route to the box, and then certian users (1 or 2 or so) that is not available to the public (ie, internet), they would be better off. i would be that with the lazy/ignorant setup of the dba/admin, that a DoS of postgresql is not the biggest problem, sure one of their redhat boxes has gotten rooted already... there is nothing that is more important for security and databases than setting them up correctly, and their place on the network. the database is the crown jewel that should never been seen or touched except for when _absolutely_ needed, and that must be under heavy control. there is a bigger problem here than postgresql, it is the dumbass factor of people that try to run a db, and are vuln to anything... and then complain about it... i find this very annoying. know what you are doing, or stfu is my opinion -chris ps -> note this was not directed at any one person, but to the mass of people that never should run a db, and go backto eating paint chips. ----- disclaimer: i do not speak on behalf of devis (devis.com). i speak on my own behalf. ----- </rant-mode> Lamar Owen writes:> On Monday 26 August 2002 10:46 am, Sir Mordred The Traitor wrote:> > Conditions: entry in a pg_hba.conffile that matches attacker's host.> > Risk: average> > > --[ Solution> >> > Disable network access for untrustedusers.> > TCP/IP access must be enabled as well. TCP/IP accessibility is OFF by > default.> > I for one thoughtthat it was normal operating procedure to only allow access > to trusted machines; maybe I'm odd in that regard.>> Hey, if I can connect to postmaster I can DoS it quite easily, but flooding it > with connection requests.....>> But, if we can thwart this, all the better.> -- > Lamar Owen> WGCR Internet Radio> 1 Peter 4:11> > ---------------------------(endof broadcast)---------------------------> TIP 3: if posting/reading through Usenet, pleasesend an appropriate> subscribe-nomail command to majordomo@postgresql.org so that your> message can get through tothe mailing list cleanly -- Chris Humphries Development InfoStructure 540.366.9809
-*- Sir Mordred The Traitor <mordred@s-mail.com> [ 2002-08-26 15:32 ]: > >Hey, if I can connect to postmaster I can DoS it quite easily, but > flooding it > >with connection requests..... > > Hm, that's true of course, but now i will do this with a couple of > connections. > Lets say, bot on a owned machine, connects to a database, > send a crafted packet, > postgresql will allocate a huge amount of memory, and will be > happy to read anything it recvs from my bot. Speaking of which. If I understand correctly, a new backend is forked and the connection dispatched to that specific backend, once access hasbeen granted (with means of user/pass authentication, ident or whatever). Is there any check for connection to the postmaster that have not been dispatched to a new backend after X bytes (or seconds?),to free resources (would that make any sense? :) And another (perhaps silly) thought: Currently, if the authentication process is exploited, it would kill the postmaster,resulting in a total crash of the whole database system. Would it be beneficial to split the connection handling/authorizationprocess to a seperate process, and if that process dies, the postmaster would simply start a new one,there for not affecting any other backends that are running (for authorized users) ? Or am I way of track? :) -- Regards, Tolli tolli@tol.li
Tom Lane wrote: > Sir Mordred The Traitor <mordred@s-mail.com> writes: > > Note, that the size of palloced memory is taken from the user's input, > > which is stupid if you ask me. > > Beyond causing an "out of memory" error during the handshake, I fail to > see how there can be any problem. palloc is considerably more robust > than malloc. > > > I dont want to provide any tools to illustrate this vulnerability. > > Perhaps you haven't tried. > > It may indeed make sense to put a range check here, but I'm getting > tired of hearing the words "dos attack" applied to conditions that > cannot be exploited to cause any real problem. All you are > accomplishing is to spread FUD among people who aren't sufficiently > familiar with the code to evaluate the seriousness of problems... Sir-* does have a point. A valid host in pg_hba.conf can cause DOS by just connecting over and over, but allocating almost all of the memory on the machine would affect other applications running on the machine, even non-networked applications, as well as PostgreSQL, while a connection DOS effects only PostgreSQL. It isn't fun to have our code nit-picked apart, and Sir-* is over-hyping the vulnerability, but it is a valid concern. The length should probably be clipped to a reasonable length and a comment put in the code describing why. There are a whole host of vulnerability scenarios that we have not explored. In fact, with 7.2.2, we got into the data-based crash vs. query-based crash issue that we have not discussed before in detail. With this report, we have a non-authorized user causing possible memory exhaustion for all applications on the server. This is a greater vulnerability than the random query argument because in such cases the user is authorized to issue queries. So, Sir-* and others, please understand that databases have their own vulnerability envelope that is much more complex than a standard network application like ftp. There is almost an entirely new vocabulary for describing such vulnerabilities which we have been crafting as we discuss it. This vocabulary includes: connection-enabled hosts vs. any hostauthenticated vs. non-authenticated usersusers with data insertion accessusers withquery access I think the last group can not be protected from malevolent queries, but the former can be tightened, and Sir-* is working on that. Sir-*, when describing vulnerabilities, especially in public forums, please try to use this language so people are not overly agitated by your warnings. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Monday 26 August 2002 12:59 pm, Bruce Momjian wrote: > Tom Lane wrote: > > It may indeed make sense to put a range check here, but I'm getting > > tired of hearing the words "dos attack" applied to conditions that > > cannot be exploited to cause any real problem. All you are > > accomplishing is to spread FUD among people who aren't sufficiently > > familiar with the code to evaluate the seriousness of problems... > It isn't fun to have our code nit-picked apart, and Sir-* is over-hyping > the vulnerability, but it is a valid concern. The length should > probably be clipped to a reasonable length and a comment put in the code > describing why. The pseudo-security-alert format used isn't terribly palatable here, IMHO. On BugTraq it might fly -- but not here. A simple 'Hey guys, I found a possible problem when.....' without the big-sounding fluff would sit better with me, at least. The substance of the message is perhaps valuable -- but the wrapper distracts from the substance. And dealing with a real name would be nice, IMHO. Otherwise we may end up with 'SMtT' as the nickname -- Hmmm, 'SMitTy' perhaps? :-) Reminds me of 'Uncle George' who did quite a bit for the Alpha port and then disappeared. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen wrote: > And dealing with a real name would be nice, IMHO. Otherwise we may end up > with 'SMtT' as the nickname -- Hmmm, 'SMitTy' perhaps? :-) Reminds me of > 'Uncle George' who did quite a bit for the Alpha port and then disappeared. Funny you mention that. Now knowing someone's name is troubling, but I am not sure why. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
> -----Original Message----- > From: Lamar Owen [mailto:lamar.owen@wgcr.org] > Sent: Monday, August 26, 2002 10:50 AM > To: Bruce Momjian; Tom Lane > Cc: Sir Mordred The Traitor; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0007: > Remove DoS in PostgreSQL > > > On Monday 26 August 2002 12:59 pm, Bruce Momjian wrote: > > Tom Lane wrote: > > > It may indeed make sense to put a range check here, but > I'm getting > > > tired of hearing the words "dos attack" applied to > conditions that > > > cannot be exploited to cause any real problem. All you are > > > accomplishing is to spread FUD among people who aren't > sufficiently > > > familiar with the code to evaluate the seriousness of problems... > > > It isn't fun to have our code nit-picked apart, and Sir-* is > > over-hyping the vulnerability, but it is a valid concern. > The length > > should probably be clipped to a reasonable length and a > comment put in > > the code describing why. > > The pseudo-security-alert format used isn't terribly > palatable here, IMHO. On > BugTraq it might fly -- but not here. An alarmist style when posting a serious error is a good idea. "Hey guys, I found a possible problem..." Does not seem to generate the needed level of excitement. DOS attacks means that business stops. I think that should generate a furrowed brow, to say the least. > A simple 'Hey guys, I > found a possible > problem when.....' without the big-sounding fluff would sit > better with me, > at least. The substance of the message is perhaps valuable > -- but the > wrapper distracts from the substance. As long as the needed data is included (here is how to reproduce the problem...) I don't see any problem. > And dealing with a real name would be nice, IMHO. Otherwise > we may end up > with 'SMtT' as the nickname -- Hmmm, 'SMitTy' perhaps? :-) > Reminds me of > 'Uncle George' who did quite a bit for the Alpha port and > then disappeared. If he wants to call himself 'Sir Modred' or 'Donald Duck' or 'Jack the Ripper' or whatever, I don't see how it matters. He is providing a valuable service by location of serious problems. These are the sort of thing that must be addressed. This is the *EXACT* sort of information that is needed to make PostgreSQL become as robust as Oracle, SQL*Server, DB/2, etc. Every free database engine project should be so lucky as to have a 'Sir Modred' IMO-YMMV.
pgman@candle.pha.pa.us (Bruce Momjian) wrote > Sir-* does have a point. A valid host in pg_hba.conf can cause DOS by > just connecting over and over, but allocating almost all of the memory > on the machine would affect other applications running on the machine, > even non-networked applications, as well as PostgreSQL, while a > connection DOS effects only PostgreSQL. oh woe is he the man who does not use rlimits, or perhaps, concurrency limits? it seems this is nothing new, all network available services are subject to dos or ddos attacks... and if you dont setup limits on your machine, then other things can be affected... inetd, bind, sendmail, finger, <insert favorite network accessible program here>, etc... I do agree that pgsql should not just arbitrarily allocate memory like this, as defensive programming, but I cannot agree that this is a bug or problem in pgsql per se. As a side note, if someone wanted to shift the discussion to allowing concurrency limits in pgsql, how would/could this fit into the context of another thread where it was discussed to be able to always allow certain users to login...
> An alarmist style when posting a serious error is a good idea. "Hey > guys, I found a possible problem..." Does not seem to generate the > needed level of excitement. DOS attacks means that business stops. I > think that should generate a furrowed brow, to say the least. Obviously people have forgotten past history. The Symbolics guys had _great_ techniques for this that were well documented: It is considered artful to append many messages on a subject, leaving only the most inflammatory lines from each, and reply to all in one swift blow. The choice of lines to support your argument can make or break your case. -- from the Symbolics Guidelines for Sending Mail % State opinions in the syntax of fact: "...as well as the bug in LMFS where you have to expunge directories to get rid of files....." -- from the Symbolics Guidelines for Sending Mail % People can be set wondering by loading obscure personal patchable systems, and sending bug reports. Who would not stop and wonder upon seeing "Experimental TD80-TAPE 1.17, MegaDeath 2.5..."? The same for provocatively-named functions and variables in stack traces. -- from the Symbolics Guidelines for Sending Mail % Know the list of "large, chronic problems". If there is any problem with the window system, blame it on the activity system. Any lack of user functionality should be attributed to the lack of a command processor. A suprisingly large number of people will believe that you have thought in depth about the issue to which you are alluding when you do. -- from the Symbolics Guidelines for Sending Mail % Know how to blow any problem up into insolubility. Know how to use the phrase "The new ~A system" to insult its argument, e.g., "I guess this destructuring LET thing is fixed in the new Lisp system", or better yet, PROLOG. -- from the Symbolics Guidelines for Sending Mail % Never hit someone head on, always sideswipe. Never say, "Foo's last patch was brain-damaged", but rather, "While fixing the miscellaneous bugs in 243.xyz [foo's patch], I found...." -- from the Symbolics Guidelines for Sending Mail % Idiosyncratic indentations, double-spacing, capitalization, etc., while stamps of individuality, leave one an easy target for parody. -- from the Symbolics Guidelines for Sending Mail % Strong language gets results. "The reloader is completely broken in 242" will open a lot more eyes than "The reloader doesn't load files with intermixed spaces, asterisks, and <'s in their names that are bigger than 64K". You can always say the latter in a later paragraph. -- from the Symbolics Guidelines for Sending Mail % Including a destination in the CC list that will cause the recipients' mailer to blow out is a good way to stifle dissent. -- from the Symbolics Guidelines for Sending Mail % When replying, it is often possible to cleverly edit the original message in such a way as to subtly alter its meaning or tone to your advantage while appearing that you are taking pains to preserve the author's intent. As a bonus, it will seem that your superior intellect is cutting through all the excess verbiage to the very heart of the matter. -- from the Symbolics Guidelines for Sending Mail % Referring to undocumented private communications allows one to claim virtually anything: "we discussed this idea in our working group last year, and concluded that it was totally brain-damaged". -- from the Symbolics Guidelines for Sending Mail % Points are awarded for getting the last word in. Drawing the conversation out so long that the original message disappears due to being indented off the right hand edge of the screen is one way to do this. Another is to imply that anyone replying further is a hopeless cretin and is wasting everyone's valuable time. -- from the Symbolics Guidelines for Sending Mail % Keeping a secret "Hall Of Flame" file of people's mail indiscretions, or copying messages to private mailing lists for subsequent derision, is good fun and also a worthwhile investment in case you need to blackmail the senders later. -- from the Symbolics Guidelines for Sending Mail % Users should cultivate an ability to make the simplest molehill into a mountain by finding controversial interpretations of innocuous sounding statements that the sender never intended or imagined. -- from the Symbolics Guidelines for Sending Mail % Obversely, a lot of verbal mileage can also be gotten by sending out incomprehensible, cryptic, confusing or unintelligible messages, and then iteratively "correcting" the "mistaken interpretations" in the replys. -- from the Symbolics Guidelines for Sending Mail % Trivialize a user's bug report by pointing out that it was fixed independently long ago in a system that hasn't been released yet. -- from the Symbolics Guidelines for Sending Mail % Send messages calling for fonts not available to the recipient(s). This can (in the case of Zmail) totally disable the user's machine and mail system for up to a whole day in some circumstances. -- from the Symbolics Guidelines for Sending Mail -- (concatenate 'string "aa454" "@freenet.carleton.ca") http://cbbrowne.com/info/emacs.html Frisbeetarianism: The belief that when you die, your soul goes up on the roof and gets stuck...
On Monday 26 August 2002 02:23 pm, Dann Corbit wrote: > An alarmist style when posting a serious error is a good idea. > "Hey guys, I found a possible problem..." > Does not seem to generate the needed level of excitement. > DOS attacks means that business stops. I think that should generate a > furrowed brow, to say the least. The historical style on this list has avoided histrionics -- although I have myself been guilty of the hyperbole problem. Making a big stink in no wise guarantees it being heard, and may very well cause some to bristle, as Tom has done. It just doesn't fit the style of this list, that's all. > As long as the needed data is included (here is how to reproduce the > problem...) I don't see any problem. When you have to read and process nearly 1,000 e-mails a day (as I have had to do, although my average is a mere 400 or so per day), the subject line and the first screenful of the message will be looked at, and no more. The substance needs to be early in the message, and the subject needs to be short and descriptive. These are just simply traditions, protocols, and ettiquette for Internet mailing lists, as well as other fora such as Usenet. If someone wants me to pay attention to a message, the subject needs to be on the point, and the point needs to be early in the message. Otherwise I may simply be so rushed when it arrives in my mailboxen (more than one, as I have autorouting mail filters in place) that it gets ignored. I know I am not alone in processing mail this way. > > And dealing with a real name would be nice, IMHO. Otherwise > > we may end up > If he wants to call himself 'Sir Modred' or 'Donald Duck' or 'Jack the > Ripper' or whatever, I don't see how it matters. He is providing a > valuable service by location of serious problems. These are the sort of > thing that must be addressed. This is the *EXACT* sort of information > that is needed to make PostgreSQL become as robust as Oracle, > SQL*Server, DB/2, etc. I'm sorry, but I have more respect for someone who isn't afraid to use their real name. I've been on both sides of that fence. Even in the security business, where people routinely use pseudonyms, I personally prefer to know their real name. If I _know_ Aleph One is Elias Levy, then that's easy enough. If the information is easily available, then that's enough. So, it makes a difference to me, like it, lump it, or think it's insane. And, yes, I agree he IS providing a valuable service -- with that I have no complaints. But there is a distinct civility and culture to this list, and I'd like to see it stay that way. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> -----Original Message----- > From: Lamar Owen [mailto:lamar.owen@wgcr.org] > Sent: Monday, August 26, 2002 11:41 AM > To: Dann Corbit; Bruce Momjian; Tom Lane > Cc: Sir Mordred The Traitor; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0007: > Remove DoS in PostgreSQL [snip] > And, yes, I agree he IS providing a valuable service -- with > that I have no > complaints. But there is a distinct civility and culture to > this list, and > I'd like to see it stay that way. I want to make it clear that I think the best way to report a problem is with formal, rigorous, complete structure. That structure should be known to the receiving body. If there is a procedure or standard form for producing the needed information, it is better to follow the standard procedure. On the other hand (and the point I had hoped to make) some people like to take lined paper and write on it sideways [Bradbury's "Fahrenheight 451" quote]. Instead of complaining that they are writing sideways on the page, extract the information of value. If the can be convinced to "stop writing in a perpendicular manner" so that the majority will be more comfortable with it, so much the better. But standardized or not, it can still contain information of great value.
Lamar Owen wrote: > And, yes, I agree he IS providing a valuable service -- with that I have no > complaints. But there is a distinct civility and culture to this list, and > I'd like to see it stay that way. Well, when someone is a "Sir", we do give them a little more latitude. (Oh, hold one, that isn't his real name. I see now.) ;-) -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Monday 26 August 2002 02:51 pm, Dann Corbit wrote: > I want to make it clear that I think the best way to report a problem is > with formal, rigorous, complete structure. That structure should be > known to the receiving body. If there is a procedure or standard form > for producing the needed information, it is better to follow the > standard procedure. Ok, let's do that then. SOP is to use the bug reporting form contained on the website, which posts a bug report to pgsql-bugs@postgresql.org, which is the canonical bugreport list. That is if we want to get that formal. > But standardized or not, > it can still contain information of great value. Yes, it can. I can use steganography to issue an RPM release announcement, too. But will it be effective? :-) If it isn't read, it won't be acted upon. His announcements have been a difficult read, that's all. The substance is OK; the presentation is lacking, IMHO. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Þórhallur Hálfdánarson <tolli@tol.li> writes:
> And another (perhaps silly) thought: Currently, if the authentication
> process is exploited, it would kill the postmaster, resulting in a
> total crash of the whole database system. Would it be beneficial to
> split the connection handling/authorization process to a seperate
> process, and if that process dies, the postmaster would simply start a
> new one, there for not affecting any other backends that are running
> (for authorized users) ? Or am I way of track? :)
No, just behind the times ;-). We did that in 7.2.
regards, tom lane