Thread: Postgresql C extension and SIGSEGV
Hi,
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?
Knowing that the extension is only used in select statement, is there a risk of (on disk) data corruption?
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)
Are there any techniques to limit/mitigate these risks? (configuration/compile flags/...)
Thanks in advance
Etienne
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. > 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. > 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. Yours, Laurenz Albe
Hi and thanks for the answer
2015-09-04 11:45 GMT+02:00 Albe Laurenz <laurenz.albe@wien.gv.at>:
I trust that the extension will not do harm on purpose, but it's C, and there is almost always bug :)
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