ubuntu/+source/postgresql-9.1:applied/ubuntu/quantal-security

Last commit made on 2014-02-24
Get this branch:
git clone -b applied/ubuntu/quantal-security https://git.launchpad.net/ubuntu/+source/postgresql-9.1
Members of Ubuntu Server Dev import team can upload to this branch. Log in for directions.

Branch merges

Branch information

Name:
applied/ubuntu/quantal-security
Repository:
lp:ubuntu/+source/postgresql-9.1

Recent commits

7141dbc... by Martin Pitt on 2014-02-20

Import patches-applied version 9.1.12-0ubuntu0.12.10 to applied/ubuntu/quantal-security

Imported using git-ubuntu import.

Changelog parent: 62332262104fe777a5ed89a8afc5f959f8f2966b
Unapplied parent: cc3314af4e67f3a4b68e3e4346d2cf9d8ac5ed13

New changelog entries:
  * New upstream security/bugfix release. (LP: #1282677)
    - Shore up GRANT ... WITH ADMIN OPTION restrictions.
      Granting a role without ADMIN OPTION is supposed to prevent the grantee
      from adding or removing members from the granted role, but this
      restriction was easily bypassed by doing SET ROLE first. The security
      impact is mostly that a role member can revoke the access of others,
      contrary to the wishes of his grantor. Unapproved role member additions
      are a lesser concern, since an uncooperative role member could provide
      most of his rights to others anyway by creating views or SECURITY
      DEFINER functions. (CVE-2014-0060)
    - Prevent privilege escalation via manual calls to PL validator functions.
      The primary role of PL validator functions is to be called implicitly
      during CREATE FUNCTION, but they are also normal SQL functions that a
      user can call explicitly. Calling a validator on a function actually
      written in some other language was not checked for and could be
      exploited for privilege-escalation purposes. The fix involves adding a
      call to a privilege-checking function in each validator function.
      Non-core procedural languages will also need to make this change to
      their own validator functions, if any. (CVE-2014-0061)
    - Avoid multiple name lookups during table and index DDL.
      If the name lookups come to different conclusions due to concurrent
      activity, we might perform some parts of the DDL on a different table
      than other parts. At least in the case of CREATE INDEX, this can be used
      to cause the permissions checks to be performed against a different
      table than the index creation, allowing for a privilege escalation
      attack. (CVE-2014-0062)
    - Prevent buffer overrun with long datetime strings.
      The MAXDATELEN constant was too small for the longest possible value of
      type interval, allowing a buffer overrun in interval_out(). Although the
      datetime input functions were more careful about avoiding buffer
      overrun, the limit was short enough to cause them to reject some valid
      inputs, such as input containing a very long timezone name. The ecpg
      library contained these vulnerabilities along with some of its own.
      (CVE-2014-0063)
    - Prevent buffer overrun due to integer overflow in size calculations.
      Several functions, mostly type input functions, calculated an allocation
      size without checking for overflow. If overflow did occur, a too-small
      buffer would be allocated and then written past. (CVE-2014-0064)
    - Prevent overruns of fixed-size buffers.
      Use strlcpy() and related functions to provide a clear guarantee that
      fixed-size buffers are not overrun. Unlike the preceding items, it is
      unclear whether these cases really represent live issues, since in most
      cases there appear to be previous constraints on the size of the input
      string. Nonetheless it seems prudent to silence all Coverity warnings of
      this type. (CVE-2014-0065)
    - Avoid crashing if crypt() returns NULL.
      There are relatively few scenarios in which crypt() could return NULL,
      but contrib/chkpass would crash if it did. One practical case in which
      this could be an issue is if libc is configured to refuse to execute
      unapproved hashing algorithms (e.g., "FIPS mode"). (CVE-2014-0066)
    - Document risks of make check in the regression testing instructions
      Since the temporary server started by make check uses "trust"
      authentication, another user on the same machine could connect to it as
      database superuser, and then potentially exploit the privileges of the
      operating-system user who started the tests. A future release will
      probably incorporate changes in the testing procedure to prevent this
      risk, but some public discussion is needed first. So for the moment,
      just warn people against using make check when there are untrusted users
      on the same machine. (CVE-2014-0067)
  * The upstream tarballs no longer contain a plain HISTORY file, but point to
    the html documentation. Add 70-history.patch to note the location of these
    files in our changelog.gz file.

cc3314a... by Martin Pitt on 2014-02-20

70-history.patch

No DEP3 Subject or Description header found

Gbp-Pq: 70-history.patch.

c5596a1... by Martin Pitt on 2014-02-20

Use Debian alternatives for external tools instead of hardcoded programs

Gbp-Pq: 54-debian-alternatives-for-external-tools.patch.

09b5c02... by Martin Pitt on 2014-02-20

Update pg_service.conf example to tell the Debian specific file location.

Gbp-Pq: 53-pg_service.conf_directory_doc.patch.

698a269... by Martin Pitt on 2014-02-20

Update tutorial README for required build dependencies.

Gbp-Pq: 52-tutorial-README.patch.

7036a05... by Martin Pitt on 2014-02-20

Put server Unix sockets into /var/run/postgresql/ by default

Gbp-Pq: 51-default-sockets-in-var.patch.

20a7194... by Martin Pitt on 2014-02-20

Use version specific installation directories so that several major versions can be installed in parallel.

Gbp-Pq: 50-per-version-dirs.patch.

ad2501b... by Martin Pitt on 2014-02-20

Relax security check on private SSL key file: The file is also considered safe if it has owner and/or group "root", and if it is group-readable (unless the group is something other than root or the database owner group).

Gbp-Pq: 02-relax-sslkey-permscheck.patch.

1a99255... by Martin Pitt on 2014-02-20

Import patches-unapplied version 9.1.12-0ubuntu0.12.10 to ubuntu/quantal-security

Imported using git-ubuntu import.

Changelog parent: c5d38a30a2bb94156ff186adb414a1098bd79f7e

New changelog entries:
  * New upstream security/bugfix release. (LP: #1282677)
    - Shore up GRANT ... WITH ADMIN OPTION restrictions.
      Granting a role without ADMIN OPTION is supposed to prevent the grantee
      from adding or removing members from the granted role, but this
      restriction was easily bypassed by doing SET ROLE first. The security
      impact is mostly that a role member can revoke the access of others,
      contrary to the wishes of his grantor. Unapproved role member additions
      are a lesser concern, since an uncooperative role member could provide
      most of his rights to others anyway by creating views or SECURITY
      DEFINER functions. (CVE-2014-0060)
    - Prevent privilege escalation via manual calls to PL validator functions.
      The primary role of PL validator functions is to be called implicitly
      during CREATE FUNCTION, but they are also normal SQL functions that a
      user can call explicitly. Calling a validator on a function actually
      written in some other language was not checked for and could be
      exploited for privilege-escalation purposes. The fix involves adding a
      call to a privilege-checking function in each validator function.
      Non-core procedural languages will also need to make this change to
      their own validator functions, if any. (CVE-2014-0061)
    - Avoid multiple name lookups during table and index DDL.
      If the name lookups come to different conclusions due to concurrent
      activity, we might perform some parts of the DDL on a different table
      than other parts. At least in the case of CREATE INDEX, this can be used
      to cause the permissions checks to be performed against a different
      table than the index creation, allowing for a privilege escalation
      attack. (CVE-2014-0062)
    - Prevent buffer overrun with long datetime strings.
      The MAXDATELEN constant was too small for the longest possible value of
      type interval, allowing a buffer overrun in interval_out(). Although the
      datetime input functions were more careful about avoiding buffer
      overrun, the limit was short enough to cause them to reject some valid
      inputs, such as input containing a very long timezone name. The ecpg
      library contained these vulnerabilities along with some of its own.
      (CVE-2014-0063)
    - Prevent buffer overrun due to integer overflow in size calculations.
      Several functions, mostly type input functions, calculated an allocation
      size without checking for overflow. If overflow did occur, a too-small
      buffer would be allocated and then written past. (CVE-2014-0064)
    - Prevent overruns of fixed-size buffers.
      Use strlcpy() and related functions to provide a clear guarantee that
      fixed-size buffers are not overrun. Unlike the preceding items, it is
      unclear whether these cases really represent live issues, since in most
      cases there appear to be previous constraints on the size of the input
      string. Nonetheless it seems prudent to silence all Coverity warnings of
      this type. (CVE-2014-0065)
    - Avoid crashing if crypt() returns NULL.
      There are relatively few scenarios in which crypt() could return NULL,
      but contrib/chkpass would crash if it did. One practical case in which
      this could be an issue is if libc is configured to refuse to execute
      unapproved hashing algorithms (e.g., "FIPS mode"). (CVE-2014-0066)
    - Document risks of make check in the regression testing instructions
      Since the temporary server started by make check uses "trust"
      authentication, another user on the same machine could connect to it as
      database superuser, and then potentially exploit the privileges of the
      operating-system user who started the tests. A future release will
      probably incorporate changes in the testing procedure to prevent this
      risk, but some public discussion is needed first. So for the moment,
      just warn people against using make check when there are untrusted users
      on the same machine. (CVE-2014-0067)
  * The upstream tarballs no longer contain a plain HISTORY file, but point to
    the html documentation. Add 70-history.patch to note the location of these
    files in our changelog.gz file.

6233226... by Martin Pitt on 2013-12-03

Import patches-applied version 9.1.11-0ubuntu0.12.10 to applied/ubuntu/quantal-proposed

Imported using git-ubuntu import.

Changelog parent: fd336003568aa5a2fe8876965109ee346abf0fea
Unapplied parent: f8abff3f2ae358b5b8fbfbba008e91d90f49a645

New changelog entries:
  * New upstream bug fix release. (LP: #1257211)
    - Fix "VACUUM"'s tests to see whether it can update relfrozenxid.
      In some cases "VACUUM" (either manual or autovacuum) could
      incorrectly advance a table's relfrozenxid value, allowing tuples
      to escape freezing, causing those rows to become invisible once
      2^31 transactions have elapsed. The probability of data loss is
      fairly low since multiple incorrect advancements would need to
      happen before actual loss occurs, but it's not zero. Users
      upgrading from releases 9.0.4 or 8.4.8 or earlier are not affected,
      but all later versions contain the bug.
      The issue can be ameliorated by, after upgrading, vacuuming all
      tables in all databases while having vacuum_freeze_table_age set to
      zero. This will fix any latent corruption but will not be able to
      fix all pre-existing data errors. However, an installation can be
      presumed safe after performing this vacuuming if it has executed
      fewer than 2^31 update transactions in its lifetime (check this
      with SELECT txid_current() < 2^31).
    - Fix initialization of "pg_clog" and "pg_subtrans" during hot
      standby startup.
      This bug can cause data loss on standby servers at the moment they
      start to accept hot-standby queries, by marking committed
      transactions as uncommitted. The likelihood of such corruption is
      small unless, at the time of standby startup, the primary server
      has executed many updating transactions since its last checkpoint.
      Symptoms include missing rows, rows that should have been deleted
      being still visible, and obsolete versions of updated rows being
      still visible alongside their newer versions.
      This bug was introduced in versions 9.3.0, 9.2.5, 9.1.10, and
      9.0.14. Standby servers that have only been running earlier
      releases are not at risk. It's recommended that standby servers
      that have ever run any of the buggy releases be re-cloned from the
      primary (e.g., with a new base backup) after upgrading.
    - See HISTORY/changelog.gz for details about other bug fixes.