Etienne Champetier wrote: > We are planning to add a C extension (https://github.com/petropavel13/pg_rrule) to our shared > postgresql cluster, and wondering what are the risk? (looking for the worst case scenario here) > > If there is a SIGSEGV, SIGBUS, SIGABRT ..., is the whole server stopping, or just the request?
All client connections will be terminated and the server will initiate recovery from the latest checkpoint. Until that is done, no client can connect to the database.
That is something you normally don't want to have in a production database.
ok, so hitting assert() is bad(tm) and i should really prevent all SIG* from happening
> Knowing that the extension is only used in select statement, is there a risk of (on disk) data > corruption?
Even when run from a SELECT, a C function can do anything it wants with the server.
I'm thinking about "trusted" code with bugs in it, like out of bound write or ...
> Is the risk limited to the current database? (the extension will only be used by 1 application with 1 > database, and we prefer not to impact other applications/databases)
The C function can happily start removing arbitrary file owned by the PostgreSQL user if it chooses to, so no. > Are there any techniques to limit/mitigate these risks? (configuration/compile flags/...)
You should only use C functions that you trust.
Code review of the extension and good testing are your best protection.
I trust that the extension will not do harm on purpose, but it's C, and there is almost always bug :)
pg_rrule use libical, which id 50k sloc, so code review is out, but i've already tested all the data in the database,
and i'm playing with afl-fuzz (and already found a cool out of bound write)
