1. 13 Jul, 2002 1 commit
  2. 20 Jun, 2002 1 commit
  3. 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
  4. 11 Jun, 2002 1 commit
    • Jan Wieck's avatar
      Katherine Ward wrote: · 469cb65a
      Jan Wieck authored
      > Changes to avoid collisions with WIN32 & MFC names...
      > 1.  Renamed:
      >       a.  PROC => PGPROC
      >       b.  GetUserName() => GetUserNameFromId()
      >       c.  GetCurrentTime() => GetCurrentDateTime()
      >       d.  IGNORE => IGNORE_DTF in include/utils/datetime.h & utils/adt/datetim
      >
      > 2.  Added _P to some lex/yacc tokens:
      >       CONST, CHAR, DELETE, FLOAT, GROUP, IN, OUT
      
      Jan
      469cb65a
  5. 28 May, 2002 1 commit
  6. 17 May, 2002 1 commit
    • Tom Lane's avatar
      Merge the last few variable.c configuration variables into the generic · f0811a74
      Tom Lane authored
      GUC support.  It's now possible to set datestyle, timezone, and
      client_encoding from postgresql.conf and per-database or per-user
      settings.  Also, implement rollback of SET commands that occur in a
      transaction that later fails.  Create a SET LOCAL var = value syntax
      that sets the variable only for the duration of the current transaction.
      All per previous discussions in pghackers.
      f0811a74
  7. 05 May, 2002 1 commit
  8. 04 Apr, 2002 1 commit
    • Bruce Momjian's avatar
      Authentication improvements: · 43a3543a
      Bruce Momjian authored
      A new pg_hba.conf column, USER
      Allow specifiction of lists of users separated by commas
      Allow group names specified by +
      Allow include files containing lists of users specified by @
      Allow lists of databases, and database files
      Allow samegroup in database column to match group name matching dbname
      Removal of secondary password files
      Remove pg_passwd utility
      Lots of code cleanup in user.c and hba.c
      New data/global/pg_pwd format
      New data/global/pg_group file
      43a3543a
  9. 15 Mar, 2002 1 commit
  10. 04 Mar, 2002 1 commit
  11. 02 Mar, 2002 2 commits
    • Bruce Momjian's avatar
      Commit to match discussed elog() changes. Only update is that LOG is · a033daf5
      Bruce Momjian authored
      now just below FATAL in server_min_messages.  Added more text to
      highlight ordering difference between it and client_min_messages.
      
      ---------------------------------------------------------------------------
      
      REALLYFATAL => PANIC
      STOP => PANIC
      New INFO level the prints to client by default
      New LOG level the prints to server log by default
      Cause VACUUM information to print only to the client
      NOTICE => INFO where purely information messages are sent
      DEBUG => LOG for purely server status messages
      DEBUG removed, kept as backward compatible
      DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1 added
      DebugLvl removed in favor of new DEBUG[1-5] symbols
      New server_min_messages GUC parameter with values:
              DEBUG[5-1], INFO, NOTICE, ERROR, LOG, FATAL, PANIC
      New client_min_messages GUC parameter with values:
              DEBUG[5-1], LOG, INFO, NOTICE, ERROR, FATAL, PANIC
      Server startup now logged with LOG instead of DEBUG
      Remove debug_level GUC parameter
      elog() numbers now start at 10
      Add test to print error message if older elog() values are passed to elog()
      Bootstrap mode now has a -d that requires an argument, like postmaster
      a033daf5
    • Tom Lane's avatar
      Add code to allow profiling of backends on Linux: save and restore the · 8d8aa931
      Tom Lane authored
      profiling timer setting across fork().  The correct way to build a
      profilable backend on Linux is now gmake PROFILE="-pg -DLINUX_PROFILE"
      8d8aa931
  12. 23 Feb, 2002 1 commit
  13. 19 Feb, 2002 2 commits
  14. 10 Jan, 2002 1 commit
  15. 06 Jan, 2002 1 commit
  16. 04 Dec, 2001 1 commit
  17. 12 Nov, 2001 1 commit
  18. 11 Nov, 2001 1 commit
  19. 10 Nov, 2001 1 commit
  20. 06 Nov, 2001 1 commit
  21. 05 Nov, 2001 1 commit
  22. 04 Nov, 2001 2 commits
    • Tom Lane's avatar
      Fix now-obsolete comment. · 430cd88a
      Tom Lane authored
      430cd88a
    • Tom Lane's avatar
      Merge three existing ways of signaling postmaster from child processes, · fb5f1b2c
      Tom Lane authored
      so that only one signal number is used not three.  Flags in shared
      memory tell the reason(s) for the current signal.  This method is
      extensible to handle more signal reasons without chewing up even more
      signal numbers, but the immediate reason is to keep pg_pwd reloads
      separate from SIGHUP processing in the postmaster.
      Also clean up some problems in the postmaster with delayed response to
      checkpoint status changes --- basically, it wouldn't schedule a checkpoint
      if it wasn't getting connection requests on a regular basis.
      fb5f1b2c
  23. 02 Nov, 2001 1 commit
  24. 28 Oct, 2001 1 commit
  25. 25 Oct, 2001 1 commit
  26. 22 Oct, 2001 1 commit
    • Tom Lane's avatar
      Further cleanup of ps_status setup code. On platforms where the · 94daee3c
      Tom Lane authored
      environment strings need to be moved around, do so when called from
      initial startup (main.c), not in init_ps_status.  This eliminates the
      former risk of invalidating saved environment-string pointers, since
      no code has yet had a chance to grab any such pointers when main.c
      is running.
      94daee3c
  27. 21 Oct, 2001 1 commit
  28. 19 Oct, 2001 4 commits
  29. 03 Oct, 2001 1 commit
  30. 30 Sep, 2001 1 commit
  31. 21 Sep, 2001 2 commits