On Mon, Feb 28, 2011 at 1:00 PM, Paweł Hajdan, Jr. <[email protected]>wrote:
> On Mon, Feb 28, 2011 at 15:12, Richard Hipp <[email protected]> wrote: > >> On Mon, Feb 28, 2011 at 8:36 AM, Paweł Hajdan, Jr. < >> [email protected]> 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); > There are 2 billion instances of SQLite in active use today. We don't want to go changing interfaces unless we absolutely have to. And there are additional complications. Based on what we can figure out about how your sandbox works, you'll also need overloads for access(), stat(), and unlink(). Presumably you have no need for dlopen() which is used for run-time loadable extensions to SQLite, but if you use that features you'll need an overload for it too. We might yet think of others, but already we see there are at least three interfaces (we could probably combine access and stat) that need to be overloaded. We are also concerned about locking. The documentation on Chromium sandboxing implies that a separate process does the open() and then sends over a file descriptor using IPC. (I didn't know you could do that in unix. In fact, I bet it requires a linux-only extension of some kind. Correct me if I'm wrong.) But that makes us very concerned about how posix advisory locking will behave. Posix advisory locks are mis-designed. See http://www.sqlite.org/src/artifact/64a2e0ebbb?ln=621,685 Are you sure that posix advisory locking will work on a file descriptor that was allocated in a different process? Have you tested it? So this all gets very complicated very fast. And very hard to test. Suggestions: (1) Let's move this discussion to [email protected] (2) Can you set up a conf-call or video-conf between the Chromium developers who have an interest in this and the SQLite development team so that we can talk through the issues? -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
