1. 25 Apr, 2003 1 commit
    • Tom Lane's avatar
      In the continuing saga of FE/BE protocol revisions, add reporting of · 9cbaf721
      Tom Lane authored
      initial values and runtime changes in selected parameters.  This gets
      rid of the need for an initial 'select pg_client_encoding()' query in
      libpq, bringing us back to one message transmitted in each direction
      for a standard connection startup.  To allow server version to be sent
      using the same GUC mechanism that handles other parameters, invent the
      concept of a never-settable GUC parameter: you can 'show server_version'
      but it's not settable by any GUC input source.  Create 'lc_collate' and
      'lc_ctype' never-settable parameters so that people can find out these
      settings without need for pg_controldata.  (These side ideas were all
      discussed some time ago in pgsql-hackers, but not yet implemented.)
      9cbaf721
  2. 24 Apr, 2003 1 commit
    • Tom Lane's avatar
      Infrastructure for upgraded error reporting mechanism. elog.c is · f690920a
      Tom Lane authored
      rewritten and the protocol is changed, but most elog calls are still
      elog calls.  Also, we need to contemplate mechanisms for controlling
      all this functionality --- eg, how much stuff should appear in the
      postmaster log?  And what API should libpq expose for it?
      f690920a
  3. 22 Apr, 2003 1 commit
    • Tom Lane's avatar
      Another round of protocol changes. Backend-to-frontend messages now all · 5ed27e35
      Tom Lane authored
      have length words.  COPY OUT reimplemented per new protocol: it doesn't
      need \. anymore, thank goodness.  COPY BINARY to/from frontend works,
      at least as far as the backend is concerned --- libpq's PQgetline API
      is not up to snuff, and will have to be replaced with something that is
      null-safe.  libpq uses message length words for performance improvement
      (no cycles wasted rescanning long messages), but not yet for error
      recovery.
      5ed27e35
  4. 19 Apr, 2003 1 commit
  5. 17 Apr, 2003 1 commit
  6. 16 Oct, 2002 1 commit
  7. 14 Oct, 2002 1 commit
  8. 03 Oct, 2002 1 commit
  9. 04 Sep, 2002 1 commit
  10. 03 Sep, 2002 1 commit
  11. 18 Aug, 2002 2 commits
  12. 17 Aug, 2002 1 commit
  13. 20 Jul, 2002 1 commit
    • Bruce Momjian's avatar
      Hello, i noticed that win32 native stopped working/compiling after the SSL merge · b6d2faaf
      Bruce Momjian authored
      .
      So i took the opportunity to fix some stuff:
      
      1. Made the thing compile (typos & needed definitions) with the new pqsecure_* s
      tuff, and added fe-secure.c to the win32.mak makefile.
      2. Fixed some MULTIBYTE compile errors (when building without MB support).
      3. Made it do that you can build with debug info: "nmake -f win32.mak DEBUG=1".
      4. Misc small compiler speedup changes.
      
      The resulting .dll has been tested in production, and everything seems ok.
      I CC:ed -hackers because i'm not sure about two things:
      
      1. In libpq-int.h I typedef ssize_t as an int because Visual C (v6.0)
      doesn't de fine ssize_t. Is that ok, or is there any standard about what
      type should be use d for ssize_t?
      
      2. To keep the .dll api consistent regarding MULTIBYTE I just return -1
      in fe-connect.c:PQsetClientEncoding() instead of taking away the whole
      function. I wonder if i should do any compares with the
      conn->client_encoding and return 0 if not hing would have changed (if so
      how do i check that?).
      
      Regards
      
      Magnus Naeslund
      b6d2faaf
  14. 20 Jun, 2002 1 commit
  15. 15 Jun, 2002 1 commit
  16. 14 Jun, 2002 3 commits
    • Bruce Momjian's avatar
      UPDATED PATCH: · 19570420
      Bruce Momjian authored
      Attached are a revised set of SSL patches.  Many of these patches
      are motivated by security concerns, it's not just bug fixes.  The key
      differences (from stock 7.2.1) are:
      
      *) almost all code that directly uses the OpenSSL library is in two
         new files,
      
           src/interfaces/libpq/fe-ssl.c
           src/backend/postmaster/be-ssl.c
      
         in the long run, it would be nice to merge these two files.
      
      *) the legacy code to read and write network data have been
         encapsulated into read_SSL() and write_SSL().  These functions
         should probably be renamed - they handle both SSL and non-SSL
         cases.
      
         the remaining code should eliminate the problems identified
         earlier, albeit not very cleanly.
      
      *) both front- and back-ends will send a SSL shutdown via the
         new close_SSL() function.  This is necessary for sessions to
         work properly.
      
         (Sessions are not yet fully supported, but by cleanly closing
         the SSL connection instead of just sending a TCP FIN packet
         other SSL tools will be much happier.)
      
      *) The client certificate and key are now expected in a subdirectory
         of the user's home directory.  Specifically,
      
      	- the directory .postgresql must be owned by the user, and
      	  allow no access by 'group' or 'other.'
      
      	- the file .postgresql/postgresql.crt must be a regular file
      	  owned by the user.
      
      	- the file .postgresql/postgresql.key must be a regular file
      	  owned by the user, and allow no access by 'group' or 'other'.
      
         At the current time encrypted private keys are not supported.
         There should also be a way to support multiple client certs/keys.
      
      *) the front-end performs minimal validation of the back-end cert.
         Self-signed certs are permitted, but the common name *must*
         match the hostname used by the front-end.  (The cert itself
         should always use a fully qualified domain name (FDQN) in its
         common name field.)
      
         This means that
      
      	  psql -h eris db
      
         will fail, but
      
      	  psql -h eris.example.com db
      
         will succeed.  At the current time this must be an exact match;
         future patches may support any FQDN that resolves to the address
         returned by getpeername(2).
      
         Another common "problem" is expiring certs.  For now, it may be
         a good idea to use a very-long-lived self-signed cert.
      
         As a compile-time option, the front-end can specify a file
         containing valid root certificates, but it is not yet required.
      
      *) the back-end performs minimal validation of the client cert.
         It allows self-signed certs.  It checks for expiration.  It
         supports a compile-time option specifying a file containing
         valid root certificates.
      
      *) both front- and back-ends default to TLSv1, not SSLv3/SSLv2.
      
      *) both front- and back-ends support DSA keys.  DSA keys are
         moderately more expensive on startup, but many people consider
         them preferable than RSA keys.  (E.g., SSH2 prefers DSA keys.)
      
      *) if /dev/urandom exists, both client and server will read 16k
         of randomization data from it.
      
      *) the server can read empheral DH parameters from the files
      
           $DataDir/dh512.pem
           $DataDir/dh1024.pem
           $DataDir/dh2048.pem
           $DataDir/dh4096.pem
      
         if none are provided, the server will default to hardcoded
         parameter files provided by the OpenSSL project.
      
      Remaining tasks:
      
      *) the select() clauses need to be revisited - the SSL abstraction
         layer may need to absorb more of the current code to avoid rare
         deadlock conditions.  This also touches on a true solution to
         the pg_eof() problem.
      
      *) the SIGPIPE signal handler may need to be revisited.
      
      *) support encrypted private keys.
      
      *) sessions are not yet fully supported.  (SSL sessions can span
         multiple "connections," and allow the client and server to avoid
         costly renegotiations.)
      
      *) makecert - a script that creates back-end certs.
      
      *) pgkeygen - a tool that creates front-end certs.
      
      *) the whole protocol issue, SASL, etc.
      
       *) certs are fully validated - valid root certs must be available.
          This is a hassle, but it means that you *can* trust the identity
          of the server.
      
       *) the client library can handle hardcoded root certificates, to
          avoid the need to copy these files.
      
       *) host name of server cert must resolve to IP address, or be a
          recognized alias.  This is more liberal than the previous
          iteration.
      
       *) the number of bytes transferred is tracked, and the session
          key is periodically renegotiated.
      
       *) basic cert generation scripts (mkcert.sh, pgkeygen.sh).  The
          configuration files have reasonable defaults for each type
          of use.
      
      Bear Giles
      19570420
    • Bruce Momjian's avatar
      eb43af32
    • Bruce Momjian's avatar
      Attached are a revised set of SSL patches. Many of these patches · a9bd1761
      Bruce Momjian authored
      are motivated by security concerns, it's not just bug fixes.  The key
      differences (from stock 7.2.1) are:
      
      *) almost all code that directly uses the OpenSSL library is in two
         new files,
      
           src/interfaces/libpq/fe-ssl.c
           src/backend/postmaster/be-ssl.c
      
         in the long run, it would be nice to merge these two files.
      
      *) the legacy code to read and write network data have been
         encapsulated into read_SSL() and write_SSL().  These functions
         should probably be renamed - they handle both SSL and non-SSL
         cases.
      
         the remaining code should eliminate the problems identified
         earlier, albeit not very cleanly.
      
      *) both front- and back-ends will send a SSL shutdown via the
         new close_SSL() function.  This is necessary for sessions to
         work properly.
      
         (Sessions are not yet fully supported, but by cleanly closing
         the SSL connection instead of just sending a TCP FIN packet
         other SSL tools will be much happier.)
      
      *) The client certificate and key are now expected in a subdirectory
         of the user's home directory.  Specifically,
      
      	- the directory .postgresql must be owned by the user, and
      	  allow no access by 'group' or 'other.'
      
      	- the file .postgresql/postgresql.crt must be a regular file
      	  owned by the user.
      
      	- the file .postgresql/postgresql.key must be a regular file
      	  owned by the user, and allow no access by 'group' or 'other'.
      
         At the current time encrypted private keys are not supported.
         There should also be a way to support multiple client certs/keys.
      
      *) the front-end performs minimal validation of the back-end cert.
         Self-signed certs are permitted, but the common name *must*
         match the hostname used by the front-end.  (The cert itself
         should always use a fully qualified domain name (FDQN) in its
         common name field.)
      
         This means that
      
      	  psql -h eris db
      
         will fail, but
      
      	  psql -h eris.example.com db
      
         will succeed.  At the current time this must be an exact match;
         future patches may support any FQDN that resolves to the address
         returned by getpeername(2).
      
         Another common "problem" is expiring certs.  For now, it may be
         a good idea to use a very-long-lived self-signed cert.
      
         As a compile-time option, the front-end can specify a file
         containing valid root certificates, but it is not yet required.
      
      *) the back-end performs minimal validation of the client cert.
         It allows self-signed certs.  It checks for expiration.  It
         supports a compile-time option specifying a file containing
         valid root certificates.
      
      *) both front- and back-ends default to TLSv1, not SSLv3/SSLv2.
      
      *) both front- and back-ends support DSA keys.  DSA keys are
         moderately more expensive on startup, but many people consider
         them preferable than RSA keys.  (E.g., SSH2 prefers DSA keys.)
      
      *) if /dev/urandom exists, both client and server will read 16k
         of randomization data from it.
      
      *) the server can read empheral DH parameters from the files
      
           $DataDir/dh512.pem
           $DataDir/dh1024.pem
           $DataDir/dh2048.pem
           $DataDir/dh4096.pem
      
         if none are provided, the server will default to hardcoded
         parameter files provided by the OpenSSL project.
      
      Remaining tasks:
      
      *) the select() clauses need to be revisited - the SSL abstraction
         layer may need to absorb more of the current code to avoid rare
         deadlock conditions.  This also touches on a true solution to
         the pg_eof() problem.
      
      *) the SIGPIPE signal handler may need to be revisited.
      
      *) support encrypted private keys.
      
      *) sessions are not yet fully supported.  (SSL sessions can span
         multiple "connections," and allow the client and server to avoid
         costly renegotiations.)
      
      *) makecert - a script that creates back-end certs.
      
      *) pgkeygen - a tool that creates front-end certs.
      
      *) the whole protocol issue, SASL, etc.
      
       *) certs are fully validated - valid root certs must be available.
          This is a hassle, but it means that you *can* trust the identity
          of the server.
      
       *) the client library can handle hardcoded root certificates, to
          avoid the need to copy these files.
      
       *) host name of server cert must resolve to IP address, or be a
          recognized alias.  This is more liberal than the previous
          iteration.
      
       *) the number of bytes transferred is tracked, and the session
          key is periodically renegotiated.
      
       *) basic cert generation scripts (mkcert.sh, pgkeygen.sh).  The
          configuration files have reasonable defaults for each type
          of use.
      
      Bear Giles
      a9bd1761
  17. 05 Mar, 2002 2 commits
    • Bruce Momjian's avatar
      Back out old version and update with newer patch of: · 6024ac1b
      Bruce Momjian authored
      	Fix for non-blocking connections in libpq
      
      Bernhard Herzog
      6024ac1b
    • Bruce Momjian's avatar
      Here's a patch against 7.1.3 that fixes a problem with sending larger · 33766e68
      Bruce Momjian authored
      queries over non-blocking connections with libpq. "Larger" here
      basically means that it doesn't fit into the output buffer.
      
      The basic strategy is to fix pqFlush and pqPutBytes.
      
      The problem with pqFlush as it stands now is that it returns EOF when an
      error occurs or when not all data could be sent. The latter case is
      clearly not an error for a non-blocking connection but the caller can't
      distringuish it from an error very well.
      
      The first part of the fix is therefore to fix pqFlush. This is done by
      to renaming it to pqSendSome which only differs from pqFlush in its
      return values to allow the caller to make the above distinction and a
      new pqFlush which is implemented in terms of pqSendSome and behaves
      exactly like the old pqFlush.
      
      The second part of the fix modifies pqPutBytes to use pqSendSome instead
      of pqFlush and to either send all the data or if not all data can be
      sent on a non-blocking connection to at least put all data into the
      output buffer, enlarging it if necessary. The callers of pqPutBytes
      don't have to be changed because from their point of view pqPutBytes
      behaves like before. It either succeeds in queueing all output data or
      fails with an error.
      
      I've also added a new API function PQsendSome which analogously to
      PQflush just calls pqSendSome. Programs using non-blocking queries
      should use this new function. The main difference is that this function
      will have to be called repeatedly (calling select() properly in between)
      until all data has been written.
      
      AFAICT, the code in CVS HEAD hasn't changed with respect to non-blocking
      queries and this fix should work there, too, but I haven't tested that
      yet.
      
      Bernhard Herzog
      33766e68
  18. 05 Nov, 2001 1 commit
  19. 02 Nov, 2001 1 commit
  20. 28 Oct, 2001 1 commit
  21. 25 Oct, 2001 1 commit
  22. 03 Oct, 2001 1 commit
  23. 17 Aug, 2001 1 commit
  24. 16 Aug, 2001 1 commit
  25. 15 Aug, 2001 1 commit
  26. 15 Jul, 2001 1 commit
  27. 06 Jul, 2001 2 commits
  28. 22 Mar, 2001 1 commit
  29. 10 Feb, 2001 1 commit
    • Tom Lane's avatar
      Restructure the key include files per recent pghackers discussion: there · d08741ea
      Tom Lane authored
      are now separate files "postgres.h" and "postgres_fe.h", which are meant
      to be the primary include files for backend .c files and frontend .c files
      respectively.  By default, only include files meant for frontend use are
      installed into the installation include directory.  There is a new make
      target 'make install-all-headers' that adds the whole content of the
      src/include tree to the installed fileset, for use by people who want to
      develop server-side code without keeping the complete source tree on hand.
      Cleaned up a whole lot of crufty and inconsistent header inclusions.
      d08741ea
  30. 24 Jan, 2001 1 commit
  31. 20 Jan, 2001 1 commit
  32. 13 Nov, 2000 2 commits
    • Bruce Momjian's avatar
      Remove -k unix socketpath option from client side, allow hostname with · ebd61ac0
      Bruce Momjian authored
      leading slash to behave as a unix socket path.
      ebd61ac0
    • Bruce Momjian's avatar
      UUNET is looking into offering PostgreSQL as a part of a managed web · 2150c2ed
      Bruce Momjian authored
      hosting product, on both shared and dedicated machines.  We currently
      offer Oracle and MySQL, and it would be a nice middle-ground.
      However, as shipped, PostgreSQL lacks the following features we need
      that MySQL has:
      
      1. The ability to listen only on a particular IP address.  Each
         hosting customer has their own IP address, on which all of their
         servers (http, ftp, real media, etc.) run.
      2. The ability to place the Unix-domain socket in a mode 700 directory.
         This allows us to automatically create an empty database, with an
         empty DBA password, for new or upgrading customers without having
         to interactively set a DBA password and communicate it to (or from)
         the customer.  This in turn cuts down our install and upgrade times.
      3. The ability to connect to the Unix-domain socket from within a
         change-rooted environment.  We run CGI programs chrooted to the
         user's home directory, which is another reason why we need to be
         able to specify where the Unix-domain socket is, instead of /tmp.
      4. The ability to, if run as root, open a pid file in /var/run as
         root, and then setuid to the desired user.  (mysqld -u can almost
         do this; I had to patch it, too).
      
      The patch below fixes problem 1-3.  I plan to address #4, also, but
      haven't done so yet.  These diffs are big enough that they should give
      the PG development team something to think about in the meantime :-)
      Also, I'm about to leave for 2 weeks' vacation, so I thought I'd get
      out what I have, which works (for the problems it tackles), now.
      
      With these changes, we can set up and run PostgreSQL with scripts the
      same way we can with apache or proftpd or mysql.
      
      In summary, this patch makes the following enhancements:
      
      1. Adds an environment variable PGUNIXSOCKET, analogous to MYSQL_UNIX_PORT,
         and command line options -k --unix-socket to the relevant programs.
      2. Adds a -h option to postmaster to set the hostname or IP address to
         listen on instead of the default INADDR_ANY.
      3. Extends some library interfaces to support the above.
      4. Fixes a few memory leaks in PQconnectdb().
      
      The default behavior is unchanged from stock 7.0.2; if you don't use
      any of these new features, they don't change the operation.
      
      David J. MacKenzie
      2150c2ed
  33. 30 Aug, 2000 1 commit
  34. 27 May, 2000 1 commit