Postgresql C extension and SIGSEGV

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Hi and thanks for the answer

2015-09-04 11:45 GMT+02:00 Albe Laurenz <laurenz.albe@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