[OpenSIPS-Devel] [opensips] db_sqlite3 sql statements not escaped (#473)

[Jarrod Baumann]

As we discussed in IRC these are the results I'm having with the latest commit (which is great improvement).  I like how you enabled both options.

Using the default setup (without SQLITE_BIND) I get a core dump when fork=no and no core when fork=yes, but it still crashes.

## SQLITE_BIND=0 , fork=no, backtrace
```
Core was generated by `opensips'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fcc95822d67 in sqlite3VXPrintf (pAccum=0x7fff82e57b20, useExtended=0, fmt=0x7fcc95abacb8 "q'", ap=0x7fff82e57b68)
    at sqlite3.c:20335
20335	sqlite3.c: No such file or directory.
(gdb) bt
#0  0x00007fcc95822d67 in sqlite3VXPrintf (pAccum=0x7fff82e57b20, useExtended=0, fmt=0x7fcc95abacb8 "q'", ap=0x7fff82e57b68)
    at sqlite3.c:20335
#1  0x00007fcc95823b16 in sqlite3_vsnprintf (n=-1786179528, zBuf=0x7fff82e57b68 "(", zFormat=0x7fff82e57ba0 "", ap=0xfc00)
    at sqlite3.c:20624
#2  0x00007fcc95823bb2 in sqlite3_snprintf (n=n at entry=65536, zBuf=zBuf at entry=0x85276d <sql_buf+45> "'name='location'", 
    zFormat=zFormat at entry=0x7fcc95abacb5 "'%*q'") at sqlite3.c:20631
#3  0x00007fcc95ab97ce in db_sqlite_val2str (_c=<optimized out>, _v=<optimized out>, _s=0x85276d <sql_buf+45> "'name='location'", 
    _len=0x7fff82e57cb0) at val.c:102
#4  0x00000000005761cc in db_print_where (_c=_c at entry=0x7fcc967ce5b8, _b=_b at entry=0x852764 <sql_buf+36> "username='name='location'", 
    _l=_l at entry=65500, _k=_k at entry=0x7fff82e57e30, _o=_o at entry=0x0, _v=_v at entry=0x7fff82e57e60, _n=_n at entry=1, 
    val2str=val2str at entry=0x7fcc95ab8ff7 <db_sqlite_val2str>) at db/db_ut.c:347
#5  0x0000000000571318 in db_do_query (_h=_h at entry=0x7fcc967ce5b8, _k=0x7fff82e57e30, _op=0x0, _v=0x7fff82e57e60, _c=<optimized out>, 
    _n=1, _nc=_nc at entry=1, _o=_o at entry=0x0, _r=_r at entry=0x0, val2str=0x7fcc95ab8ff7 <db_sqlite_val2str>, 
    submit_query=submit_query at entry=0x7fcc95ab16d0 <db_sqlite_submit_dummy_query>, store_result=store_result at entry=0x0)
    at db/db_query.c:77
#6  0x00007fcc95ab1da8 in db_sqlite_query (_h=0x7fcc967ce5b8, _k=<optimized out>, _op=<optimized out>, _v=<optimized out>, 
    _c=<optimized out>, _n=<optimized out>, _nc=1, _o=0x0, _r=0x7fff82e57e50) at dbase.c:164
#7  0x00007fcc94281f07 in testdb_udomain (con=con at entry=0x7fcc967ce5b8, d=<optimized out>) at udomain.c:818
#8  0x00007fcc94274398 in register_udomain (_n=<optimized out>, _d=0x7fff82e57f10) at dlist.c:597
#9  0x00007fcc9405414e in domain_fixup (param=0x7fcc967ac3d8) at reg_mod.c:386
#10 registrar_fixup (param=0x7fcc967ac3d8, param_no=<optimized out>) at reg_mod.c:421
#11 0x00000000004a7791 in fix_actions (a=<optimized out>) at route.c:459
#12 0x00000000004aac2d in fix_expr (exp=<optimized out>) at route.c:214
#13 0x00000000004a77e0 in fix_actions (a=<optimized out>) at route.c:382
#14 0x00000000004a8da1 in fix_actions (a=<optimized out>) at route.c:386
#15 0x00000000004adfdd in fix_rls () at route.c:2063
#16 0x00000000004197cd in main (argc=<optimized out>, argv=<optimized out>) at main.c:1242
(gdb) 
```

With SQLITE_BIND=1, which I believe I prefer even though it utilizes a mutex, opensips starts but I am receiving some errors related to queries:

### SQLITE_BIND=1, opensips log output
```
Apr 22 14:11:27 localhost opensips[13074]: ERROR:db_sqlite:db_sqlite_insert: insert query failed NOT NULL constraint failed: active_watchers.reason
Apr 22 14:11:27 localhost opensips[13074]: ERROR:presence:update_db_subs: unsuccessful sql insert
Apr 22 14:13:08 localhost opensips[13068]: ERROR:db_sqlite:db_sqlite_insert: insert query failed NOT NULL constraint failed: active_watchers.reason
Apr 22 14:13:08 localhost opensips[13068]: ERROR:presence:update_db_subs: unsuccessful sql insert
```

Thanks for your work!


---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/473#issuecomment-95208475
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20150422/9dc83da0/attachment.htm>