On 2013-07-15 12:12:36 +0200, Markus Wanner wrote: > Granted, the "internalization" of the DSO is somewhat critical to > implement. Running as a non-root user, Postgres has less power than that > and can certainly not protect the internalized DSO from modification by > root. It can, however, store the DSO well protected from other users > (e.g. in a directory within $PGDATA).
There's heaps of problems with that though. Think noexec mounts or selinux. > Relying on the external DSO only exactly once can provide additional > safety. Not necessarily. Think of a distribution provided upgrade with a security fix in an extension. On a machine with dozens of clusters. Now you need to make sure each and every one of them has the new .so. > Consider an extensions directory that's accidentally > world-writable. As it stands, an attacker can modify the DSO and gain > control as soon as a new connection loads it. With my proposal, the > attacker would have to wait until CREATE EXTENSION. A point in time > where the newly created extension is more likely to be tested and > cross-checked. I think protecting against the case where such directories are writable is a rather bad argument. If anything screwed up those the postgres binaries directory itself quite likely has also been changed and such. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
