1. 07 2月, 2007 3 次提交
    • T
      Remove typmod checking from the recent security-related patches. It turns · a8c3f161
      Tom Lane 提交于
      out that ExecEvalVar and friends don't necessarily have access to a tuple
      descriptor with correct typmod: it definitely can contain -1, and possibly
      might contain other values that are different from the Var's value.
      Arguably this should be cleaned up someday, but it's not a simple change,
      and in any case typmod discrepancies don't pose a security hazard.
      Per reports from numerous people :-(
      
      I'm not entirely sure whether the failure can occur in 8.0 --- the simple
      test cases reported so far don't trigger it there.  But back-patch the
      change all the way anyway.
      a8c3f161
    • B
      Split apart entries, one done now: · 869585cc
      Bruce Momjian 提交于
      * -Move NAMEDATALEN from postgres_ext.h to pg_config_manual.h
      * Consider making NAMEDATALEN more configurable in future releases
      869585cc
    • T
      Fix typo in comment. · 28c3cd5c
      Tom Lane 提交于
      28c3cd5c
  2. 06 2月, 2007 10 次提交
  3. 05 2月, 2007 3 次提交
    • A
      Pass modern COPY syntax to backend, since copy (query) does not accept old... · 00ade1df
      Andrew Dunstan 提交于
      Pass modern COPY syntax to backend, since copy (query) does not accept old syntax. Per complaint from Michael Fuhr.
      00ade1df
    • T
      Rename MaxTupleSize to MaxHeapTupleSize to clarify that it's not meant to · 23c4978e
      Tom Lane 提交于
      describe the maximum size of index tuples (which is typically AM-dependent
      anyway); and consequently remove the bogus deduction for "special space"
      that was built into it.
      
      Adjust TOAST_TUPLE_THRESHOLD and TOAST_MAX_CHUNK_SIZE to avoid wasting two
      bytes per toast chunk, and to ensure that the calculation correctly tracks any
      future changes in page header size.  The computation had been inaccurate in a
      way that didn't cause any harm except space wastage, but future changes could
      have broken it more drastically.
      
      Fix the calculation of BTMaxItemSize, which was formerly computed as 1 byte
      more than it could safely be.  This didn't cause any harm in practice because
      it's only compared against maxalign'd lengths, but future changes in the size
      of page headers or btree special space could have exposed the problem.
      
      initdb forced because of change in TOAST_MAX_CHUNK_SIZE, which alters the
      storage of toast tables.
      23c4978e
    • T
      Don't MAXALIGN in the checks to decide whether a tuple is over TOAST's · a2e092e1
      Tom Lane 提交于
      threshold for tuple length.  On 4-byte-MAXALIGN machines, the toast code
      creates tuples that have t_len exactly TOAST_TUPLE_THRESHOLD ... but this
      number is not itself maxaligned, so if heap_insert maxaligns t_len before
      comparing to TOAST_TUPLE_THRESHOLD, it'll uselessly recurse back to
      tuptoaster.c, wasting cycles.  (It turns out that this does not happen on
      8-byte-MAXALIGN machines, because for them the outer MAXALIGN in the
      TOAST_MAX_CHUNK_SIZE macro reduces TOAST_MAX_CHUNK_SIZE so that toast tuples
      will be less than TOAST_TUPLE_THRESHOLD in size.  That MAXALIGN is really
      incorrect, but we can't remove it now, see below.)  There isn't any particular
      value in maxaligning before comparing to the thresholds, so just don't do
      that, which saves a small number of cycles in itself.
      
      These numbers should be rejiggered to minimize wasted space on toast-relation
      pages, but we can't do that in the back branches because changing
      TOAST_MAX_CHUNK_SIZE would force an initdb (by changing the contents of toast
      tables).  We can move the toast decision thresholds a bit, though, which is
      what this patch effectively does.
      
      Thanks to Pavan Deolasee for discovering the unintended recursion.
      
      Back-patch into 8.2, but not further, pending more testing.  (HEAD is about
      to get a further patch modifying the thresholds, so it won't help much
      for testing this form of the patch.)
      a2e092e1
  4. 04 2月, 2007 10 次提交
  5. 03 2月, 2007 8 次提交
  6. 02 2月, 2007 6 次提交
    • M
    • M
    • B
      Add: · 98df9001
      Bruce Momjian 提交于
      > 	o Allow column display reordering by recording a display,
      > 	  storage, and permanent id for every column?
      >
      > 	  http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php
      >
      98df9001
    • T
      Update release notes for security-related releases in all active branches. · bd01a4e3
      Tom Lane 提交于
      Security: CVE-2007-0555, CVE-2007-0556
      bd01a4e3
    • T
      Repair failure to check that a table is still compatible with a previously · 5413eef8
      Tom Lane 提交于
      made query plan.  Use of ALTER COLUMN TYPE creates a hazard for cached
      query plans: they could contain Vars that claim a column has a different
      type than it now has.  Fix this by checking during plan startup that Vars
      at relation scan level match the current relation tuple descriptor.  Since
      at that point we already have at least AccessShareLock, we can be sure the
      column type will not change underneath us later in the query.  However,
      since a backend's locks do not conflict against itself, there is still a
      hole for an attacker to exploit: he could try to execute ALTER COLUMN TYPE
      while a query is in progress in the current backend.  Seal that hole by
      rejecting ALTER TABLE whenever the target relation is already open in
      the current backend.
      
      This is a significant security hole: not only can one trivially crash the
      backend, but with appropriate misuse of pass-by-reference datatypes it is
      possible to read out arbitrary locations in the server process's memory,
      which could allow retrieving database content the user should not be able
      to see.  Our thanks to Jeff Trout for the initial report.
      
      Security: CVE-2007-0556
      5413eef8
    • T
      Repair insufficiently careful type checking for SQL-language functions: · f8eb75b6
      Tom Lane 提交于
      we should check that the function code returns the claimed result datatype
      every time we parse the function for execution.  Formerly, for simple
      scalar result types we assumed the creation-time check was sufficient, but
      this fails if the function selects from a table that's been redefined since
      then, and even more obviously fails if check_function_bodies had been OFF.
      
      This is a significant security hole: not only can one trivially crash the
      backend, but with appropriate misuse of pass-by-reference datatypes it is
      possible to read out arbitrary locations in the server process's memory,
      which could allow retrieving database content the user should not be able
      to see.  Our thanks to Jeff Trout for the initial report.
      
      Security: CVE-2007-0555
      f8eb75b6