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