Thread

1. psql can crash the backend on login

   PostgreSQL Bugs List <pgsql-bugs@postgresql.org> — 2000-09-03T16:40:58Z

   Alexandru Popa (razor@ldc.ro) reports a bug with a severity of 1
   The lower the number the more severe it is.
   
   Short Description
   psql can crash the backend on login
   
   Long Description
   On a FreeBSD 4.1-STABLE system, launching /usr/local/pgsql/bin/psql  and giving control-d as a password will crash the backend.
   Note I only tried this on a localhost connection (Unix sockets)
   
   Sample Code
   machine% /usr/local/pgsql/bin/psql -U validuser
   Password: (hit control-d here)
   Password:
   Password:
   Password:
   Password:
   Password:
   Password:
   Password:
   Password:
   (more of those)
   Password:
   psql: pqReadData() -- backend closed the channel unexpectedly.
           This probably means the backend terminated abnormally
           before or while processing the request.
   machine% /usr/local/pgsql/bin/psql -U validuser
   psql: connectDBStart() -- connect() failed: No such file or directory
           Is the postmaster running at 'localhost'
           and accepting connections on Unix socket '5432'?
   machine% ps auxw|grep 'post[m]aster'
   machine% 
   
   
   
   No file was uploaded with this report
   
   
   

2. Re: psql can crash the backend on login

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-09-03T22:16:33Z

   pgsql-bugs@postgresql.org writes:
   > machine% /usr/local/pgsql/bin/psql -U validuser
   > Password: (hit control-d here)
   > Password:
   > Password:
   > Password:
   > Password:
   > Password:
   > Password:
   > Password:
   > Password:
   > (more of those)
   > Password:
   > psql: pqReadData() -- backend closed the channel unexpectedly.
   >         This probably means the backend terminated abnormally
   >         before or while processing the request.
   > machine% /usr/local/pgsql/bin/psql -U validuser
   > psql: connectDBStart() -- connect() failed: No such file or directory
   >         Is the postmaster running at 'localhost'
   >         and accepting connections on Unix socket '5432'?
   > machine% ps auxw|grep 'post[m]aster'
   > machine% 
   
   Interesting.  What seems to be happening is that the postmaster is
   quitting because it runs out of open files.  The quit is already fixed
   in current sources, I believe; when I try this I have to hit ^D about
   180 times, but eventually I get
   
   Password:
   Password:
   Password:
   psql: Missing or erroneous pg_hba.conf file, see postmaster log for details
   $ 
   
   and in the postmaster log
   
   find_hba_entry: Unable to open authentication config file "/home/postgres/testversion/data/pg_hba.conf": Too many open files
   Missing or erroneous pg_hba.conf file, see postmaster log for details
   
   So *why* is it running out of open files?  Seems to be psql's fault:
   psql is opening a new connection for each Password: cycle, and not
   closing the old one, which is still awaiting a response to the
   postmaster's demand for a password.  psql would fail for lack of open
   files too, except the postmaster has a few more open to begin with and
   so fails first.  Haven't yet dug into why exactly (maybe the bug is in
   libpq not psql?)
   
   If you run it across TCP instead of Unix socket, there's a different
   bad behavior.  Not sure why the difference, since psql really shouldn't
   care, but it seems to be stuck inside psql's password prompting code
   in both cases.
   
   This is clearly a client-side bug, but it does point up the fact that
   clients can cause a denial-of-service problem if they open up enough
   connection requests and leave the requests hanging in an incomplete
   authentication handshake.  Perhaps we should make the postmaster
   time-out such connection requests after some not very large number
   of seconds.  People who aren't quick about typing their passwords
   might get annoyed though...
   
   			regards, tom lane