Hi and thanks for the answer 2015-09-04 11:45 GMT+02:00 Albe Laurenz <laurenz.a...@wien.gv.at>:
> 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) Just wanted to know the worst case scenario > Yours, > Laurenz Albe > Thanks again Etienne
