On 07/15/2013 12:19 PM, Andres Freund wrote: > 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.
Good point. Note, however, that "internalize" doesn't necessarily mean exactly that approach. It could be yet another directory, even system wide, which any distribution should well be able to prepare. I intentionally left the "internalizing" somewhat undefined. It could even be more equivalent to what is done with the SQL stuff, i.e. some system catalog. But that just poses other implementation issues. (Loading a DSO from memory doesn't sound very portable to me.) >> 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. Ugh.. only to figure out the patched DSO is incompatible to the old version of the SQL scripts? And therefore having to re-create the extension, anyways? That only highlights why this difference in treatment of SQL and DSO is troublesome. > On a machine with dozens of clusters. Now > you need to make sure each and every one of them has the new .so. Agreed. So this sounds like the other approach to unification may be more useful: Linking the SQL scripts better and make them (re-)load from the extensions directory, just like the DSOs. > I think protecting against the case where such directories are writable > is a rather bad argument. I agree. That's why I'm neglecting he security implications and stated there are none. Regards Markus Wanner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
