From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: logical changeset generation v6.2 |
Date: | 2013-10-15 14:34:53 |
Message-ID: | CA+TgmoaTA00iAtydeHXN8Lx_3COtYtXmGXX-jrSFqo1PEcL+Vw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 15, 2013 at 10:27 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> I think part of the problem may be that you're using the library name
>> to identify the output plugin. I'm not excited about that design.
>> For functions, you give the function a name and that is a pointer to
>> where to actually find the function, which may be a 2-tuple
>> <library-name, function-name>, or perhaps just a 1-tuple
>> <builtin-function-name>, or maybe the whole text of a PL/pgsql
>> procedure that should be compiled.
>
> That means you allow trivial remote code execution since you could try
> to load system() or something else that's available in every shared
> object. Now you can argue that that's OK since we have special checks
> for replication connections, but I'd rather not go there.
Well, obviously you can't let somebody load any library they want.
But that's pretty much true anyway; LOAD had better be confined to
superusers unless there is something (like a pg_proc entry) that
provides "prior authorization" for that specific load.
>> Perhaps this ought to work similarly. Create a function in pg_proc
>> which returns the structure containing the function pointers. Then,
>> when that output plugin is selected, it'll automatically trigger
>> loading the correct shared library if that's needed; and the shared
>> library name may (but need not) match the output plugin name.
>
> I'd like to avoid relying on inserting stuff into pg_proc because that
> makes it harder to extract WAL from a HS standby. Requiring to configure
> that on the primary to extract data on the standby seems confusing to
> me.
>
> But perhaps that's the correct solution :/
That's a reasonable concern. I don't have another idea at the moment,
unless we want to allow replication connections to issue LOAD
commands. Then you can LOAD the library, so that the plug-in is
registered under the well-known name you expect it to have, and then
use that name to start replication.
>> Now, some users are still going to head for the hills. But at least
>> from where I sit it sounds a hell of a lot better than the first
>> answer. We're not going to solve all of the tooling problems around
>> this technology in one release, for sure. But as far as 95% of our
>> users are concerned, a C API might as well not exist at all. People
>> WILL try to machine parse the output of whatever demo plugins we
>> provide; so I think we should try hard to provide at least one such
>> plugin that is designed to make that as easy as possible.
>
> Well, just providing the C API + an example in a first step didn't work
> out too badly for FDWs. I am pretty sure that once released there will
> soon be extensions for it on PGXN or whatever for special usecases.
I suspect so, too. But I also think that if that's the only thing
available in the first release, a lot of users will get a poor initial
impression.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-10-15 14:36:41 | Re: Patch for reserved connections for replication users |
Previous Message | Bruce Momjian | 2013-10-15 14:34:37 | Re: Release note fix for timeline item |