Re: Postgresql C extension and SIGSEGV

Hi and thanks for the answer

2015-09-04 11:45 GMT+02:00 Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)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