The Hermit Hacker wrote:
>
> On Fri, 16 Jan 1998, Micha3 Mosiewicz wrote:
>
> > No, no, no! For security reasons, you can't fork (and exec)
> > unauthenticated processes. Especially HBA authentication should be done
> > to consume as low resources as possbile. Otherwise you open a giant door
> > for so infamously called Denial of Service attacks. Afterwards, every
> > hacker will know that to bring your system running postgres to it's
> > knees he just have to try to connect to 5432 port very frequently. "OK",
> > you might say, "I have this firewall". "OK", I say, "so what's that HBA
> > for?".
> >
> > So it's the postmaster's role to deny as much connections as possible.
> > Unless we speak of non-execing postgres childs?
>
> Hrmmmm...i don't quite agree with this. postmaster can handle one
> connection at a time, and then has to pass it off to the postgres backend
> process...DoS attacks are easier now then by forking before HBA. I just have
> to continuously open a connection to port 5432...so, while postmaster is
> handling that connection, checking HBA, checking a password...no other new
> connections can happen. Can't think of a stronger DoS then that...? :)
I think Micha is right. The postmaster can handle multiple connections
as the read of the startup packet is done a fragment at a time without
blocking so there is no DoS problem until the postmaster runs out of
sockets. I think this is less of a problem than loads of
unauthenticated, resource hungry backends forked by the postmaster.
In changing the authentication methods for 6.3 I've had to add the
ability for the postmaster to do non-blocking writes as well as reads so
that a two-way (non-blocking) dialog can take place between frontend and
postmaster.
Having said that, I won't fix (for 6.3 anyway) other parts of the
postmaster that do blocked I/O - the ident lookup in particular.
However, it is at least under the control of the DBA whether or not
ident is used.
Phil
