One Severe and Multiple Security Fixes – PostgreSQL

If you’re using dev-db/postgresql-server, update now.

CVE-2013-1899 <dev-db/postgresql-server-{9.2.4,9.1.9,9.0.13}
------------------------------------------------------------
A connection request containing a database name that begins
with "-" may be crafted to damage or destroy files within a server's data directory.

CVE-2013-1900 <dev-db/postgresql-server-{9.2.4,9.1.9,9.0.13,8.4.17}
-------------------------------------------------------------------
Random numbers generated by contrib/pgcrypto functions may be easy for another
database user to guess

CVE-2013-1901 <dev-db/postgresql-server-{9.2.4,9.1.9}
-----------------------------------------------------
An unprivileged user can run commands that could interfere with in-progress backups.

Security Update 2012-08-17 – PostgreSQL

From PostgreSQL:

The PostgreSQL Global Development Group today released security updates for all active branches of the PostgreSQL database system, including versions 9.1.5, 9.0.9, 8.4.13 and 8.3.20. This update patches security holes associated with libxml2 and libxslt, similar to those affecting other open source projects. All users are urged to update their installations at the first available opportunity.

This security release fixes a vulnerability in the built-in XML functionality, and a vulnerability in the XSLT functionality supplied by the optional XML2 extension. Both vulnerabilities allow reading of arbitrary files by any authenticated database user, and the XSLT vulnerability allows writing files as well. The fixes cause limited backwards compatibility issues. These issues correspond to the following two vulnerabilities:

This release also contains several fixes to version 9.1, and a smaller number of fixes to older versions, including:

  • Updates and corrections to time zone data
  • Multiple documentation updates and corrections
  • Add limit on max_wal_senders
  • Fix dependencies generated during ALTER TABLE ADD CONSTRAINT USING INDEX.
  • Correct behavior of unicode conversions for PL/Python
  • Fix WITH attached to a nested set operation (UNION/INTERSECT/EXCEPT).
  • Fix syslogger so that log_truncate_on_rotation works in the first rotation.
  • Only allow autovacuum to be auto-canceled by a directly blocked process.
  • Improve fsync request queue operation
  • Prevent corner-case core dump in rfree().
  • Fix Walsender so that it responds correctly to timeouts and deadlocks
  • Several PL/Perl fixes for encoding-related issues
  • Make selectivity operators use the correct collation
  • Prevent unsuitable slaves from being selected for synchronous replication
  • Make REASSIGN OWNED work on extensions as well
  • Fix race condition with ENUM comparisons
  • Make NOTIFY cope with out-of-disk-space
  • Fix memory leak in ARRAY subselect queries
  • Reduce data loss at replication failover
  • Fix behavior of subtransactions with Hot Standby

Users who are relying on the built-in XML functionality to validate external DTDs will need to implement a workaround, as this security patch disables that functionality. Users who are using xslt_process() to fetch documents or stylesheets from external URLs will no longer be able to do so. The PostgreSQL project regrets the need to disable both of these features in order to maintain our security standards. These security issues with XML are substantially similar to issues patched recently by the Webkit (CVE-2011-1774), XMLsec (CVE-2011-1425) and PHP5 (CVE-2012-0057) projects.

As with other minor releases, users are not required to dump and reload their database or use pg_upgrade in order to apply this update release; you may simply shut down PostgreSQL and update its binaries. Perform post-update steps after the database is restarted.

All supported versions of PostgreSQL are affected. See the release notes for each version for a full list of changes with details of the fixes and steps.

The latest versions are available from Portage now.

pgpool-II 3.2.0 Now Available For Real – PostgreSQL

So, apparently pgpool-II did a bit of a switcharoo some time ago, which I wasn’t too careful about. But, can you really blame me? pgpool-II’s documentation is among the worst I’ve seen. It’s a good thing they’ve commented their code, or I wouldn’t have been able to do some things cleanly. Continue reading pgpool-II 3.2.0 Now Available For Real – PostgreSQL

PostgreSQL 8.2 EOL

PostgreSQL 8.2 has reached the end of its life. Start making your transition now.

From the release announcement (postgresql.org) on December 5, 2011:

This is also the last update for PostgreSQL 8.2, which is now End-Of-Life (EOL). Users of version 8.2 should plan to upgrade their PostgreSQL installations to 8.3 or later within the next couple of months. For more information, see our Release Support Policy. [wiki.postgresql.org]

/run? /var/run? Other? Or Why You Need to Update to the Latest PostgreSQL Initscript

The PostgreSQL ebuilds and initscript are now capable of using either /run or /var/run for the default socket directory.

The ebuilds will determine which to use at build time. The logic simply being, “Does /run exist?” If it does, everything is adjusted accordingly. If not, everything is adjusted accordingly. The old initscript is incapable of using /run or any other socket directory. So, if you upgrade to the latest version of the ebuilds and fail to upgrade the initscript, you’re going to have issues if you have a /run directory.

Also, this may cause a hiccup when an application is expecting the default location to be in /var/run/postgresql rather than /run/postgresql. The proper solution is not to rebuild everything — you can if you want, but that’s time consuming — but to specify the directory to look in for the socket. Anywhere you’d specify the host you can actually specify the socket directory. Or, you should be able to if the application did it right.

Something that is more important for those who have /run or /var/run on tmpfs, the initscript now takes care of creating the directory if it’s missing. With proper permissions of course.

The next neat thing is that the initscript respects two settings it previously ignored. Well, it ignored one setting outright, and allowed you to set another in /etc/conf.d/postgresql-${SLOT} only. If you set port or socket_directory in the postgresql.conf, the initscript will now pick it up and use those settings over what’s set in /etc/conf.d/postgresql-${SLOT}.

The growing pains aren’t over just yet. Out of three machines, one machine didn’t like the new initscript. It couldn’t shutdown an existing, running server. The other two did it just fine. Same setups. Nothing fancy. Just inexplicable. It’s easy enough to shutdown the server manually, and cleanly. Issue the following substituting the path for wherever your server’s data directory actually resides.

# kill -SIGTERM $(head -n1 /var/lib/postgresql/9.1/data/postmaster.pid)

If that doesn’t do the trick, you can substitute -SIGTERM with -SIGINT as that will close client connections and rollback the transactions those clients may have been in, as that is the most common cause as to why -SIGTERM wouldn’t work.

Merry Christmas!