Re: Proposal: template-ify (binary) extensions
От | Andres Freund |
---|---|
Тема | Re: Proposal: template-ify (binary) extensions |
Дата | |
Msg-id | 20130715101940.GA12007@alap2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Proposal: template-ify (binary) extensions (Markus Wanner <markus@bluegap.ch>) |
Ответы |
Re: Proposal: template-ify (binary) extensions
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: