On Mon, Feb 28, 2011 at 15:12, Richard Hipp <d...@sqlite.org> wrote:
> On Mon, Feb 28, 2011 at 8:36 AM, Paweł Hajdan, Jr. <
> phajdan...@chromium.org> wrote:
>
>>
>> I remember a part of earlier discussion that there is a problem with
>> journal and possibly other auxiliary files, i.e. we can't create/open them
>> just based on one file descriptor.
>>
>
> Right. If you call sqlite3_open("xyzzy",...) then you end up opening
> various files, including but no limited to "xyzzy", "xyzzy-journal",
> "xyzzy-wal", and "xyzzy-shm".
>
I see. Does sqlite call the VFS's xOpen function for each of those files?
I'd need your advice on the above, i.e. assuming that the code can't call
>> open directly (the call will fail because of the sandbox) but it can ask the
>> browser process to open a file and send back a file descriptor.
>>
>> It is possible that instead of this entire xFdOpen thing that I suggested,
>> it would be better to make it possible to pass a custom function used by
>> sqlite instead of POSIX's open. In this case, that would roughly
>> be PlatformBridge::databaseOpenFile.
>>
>
> Can't you simply compile the standard "sqlite3.c" amalgamated source file
> using
>
> -Dopen=openUsingPlatformBridge
>
> and then implement a single function openUsingPlatformBridge() that does
> all the necessary magic for you?
>
It has two drawbacks I'd like to avoid:
1) It requires two copies of sqlite code, one compiled with
openUsingPlatformBridge (for the renderer), and one using the real open (for
the browser)
2) It requires a non-standard compilation of sqlite, and ideally the
solution should work with a vanilla sqlite, for example as shipped by Linux
distributions.
What do you think about adding a call like below to the VFS interface?
int (*xOpenWrapper)(const char *path, int flags, int mode);
This roughly corresponds to open's signature from fcntl.h (man 2 open), and
"by default" it would be just the real open. Chromium would
substitute PlatformBridge::databaseOpenFile in that place in its own VFS
(and re-use most of other calls from the "unix" VFS).
Of course such a call is not cross-platform, so I know it's not going to get
accepted. However, I'm wondering what you think about it (assuming for a
while we don't care about other platforms), and maybe you have some ideas
for interfaces to make sqlite's os_unix VFS obtain the file descriptor in
other way than just calling open.
Also, this is not necessarily POSIX-only. Chromium also has a similar hack
for Windows, just a HANDLE is passed instead of an int file descriptor.
On Mon, Feb 28, 2011 at 17:16, Nico Williams <n...@cryptonector.com> wrote:
> It's not much of a sandbox if you let the sandbox have direct access
> to SQLite3 DB files... I worry that a compromised sandbox could muck
> with the database in ways that are more harmful than merely
> inserting/updating/deleting random rows.
>
If the database file we give it is only ever used by the sandboxed
processes, that should be fine, right? They can only break themselves.
Anyway, that's slightly beyond the topic, as I didn't design the original
Chromium code that handles it.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
