That is the intended usage of SQLite. That's part of the threat model for it in the real world and it certainly aims to be safe in that case. It's also supposed to remain memory safe with a lot of attacker control over the database queries.
Conversation
sqlite.org/whentouse.html
SQLite does not compete with client/server databases. SQLite competes with fopen().
It's intended for all kinds of structured data, including configuration files and things like thumbnail caches. It's the goal of the project to be used like that.
1
1
Data owned by the same user/privilege context that reads it. You should not be sharing this kind of data between privilege contexts regardless of the format it's in.
1
Only data in standard serialized formats for transmission should be shared between privilege contexts. Ever.
1
SQLite is intended to be a standard serialized format for transmission. Please read through sqlite.org/whentouse.html. It's intended to be used for things like an implementation of the file format for GIMP or a word processor. It's not trying to be an alternative to MySQL.
1
1
Then that's an obviously bad intent incompatible with their security policy. Nobody should be using db files for information interchange.
2
What do you mean incompatible with their security policy? They have one of the strongest attempts at writing correct and safe C code that I've seen in any project. They have extensive testing and fuzzing of the database format including applying dynamic analysis features.
1
If you mean this quote: twitter.com/vyodaiken/stat. That quote is explaining that running arbitrary SQL is not supposed to be safe even if language features are disabled. In the next paragraph, it speaks about *confidence* in the handling of untrusted database files in contrast.
This Tweet is unavailable.
1
1
And it is true that they do a great job limiting the attack surface, writing clear / simple code and applying amazingly thorough testing that I've never seen in any other open source project. If SQLite's approach to security with C is not good enough then it's clearly not doable.
1
1
And they do still have occasional memory corruption bugs shipped in production via both database files and perfectly normal / trusted SQL statements. It's unreasonable to say they are being irresponsible, not writing good enough code or not doing enough testing. They're great.
1
1
The issue is that despite all of that, there are still occasional memory corruption bugs in a complex program. I could be talking about something like audio and video codecs / containers but I picked SQLite because I can't come up with a better written and tested example.