On Tue, Oct 15, 2013 at 10:27 AM, Andres Freund <and...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
