Fix WebSQL error on sandboxed OSX and Linux.

Source/modules/webdatabase/sqlite/SQLiteFileSystemPosix.cpp

Index: Source/modules/webdatabase/sqlite/SQLiteFileSystemPosix.cpp
diff --git a/Source/modules/webdatabase/sqlite/SQLiteFileSystemPosix.cpp b/Source/modules/webdatabase/sqlite/SQLiteFileSystemPosix.cpp
index 9b85a6e74cdfe761ad82bffc5ac4225bdb178634..fef04088f1bfacd9092a17f1684592d83be72ed5 100644
--- a/Source/modules/webdatabase/sqlite/SQLiteFileSystemPosix.cpp
+++ b/Source/modules/webdatabase/sqlite/SQLiteFileSystemPosix.cpp
@@ -52,6 +52,93 @@ namespace blink {
 // Chromium's Posix implementation of SQLite VFS
 namespace {
 
+struct chromiumVfsFile {
+    sqlite3_io_methods* pMethods;
+    sqlite3_file* realFile;
+    char* fileName;
+};
+
+int chromiumClose(sqlite3_file* fi)
+{
+    chromiumVfsFile* f = (chromiumVfsFile*)fi;
+    int r = f->realFile->pMethods->xClose(f->realFile);
+    sqlite3_free(f->fileName);
+    sqlite3_free(f->realFile);
+    memset(f, 0, sizeof(*f));
+    return r;
+}
+
+int chromiumRead(sqlite3_file* fi, void* pBuf, int iAmt, sqlite3_int64 iOfst)
+{
+    chromiumVfsFile* f = (chromiumVfsFile*)fi;
+    return f->realFile->pMethods->xRead(f->realFile, pBuf, iAmt, iOfst);
+}
+
+int chromiumWrite(sqlite3_file* fi, const void* pBuf, int iAmt, sqlite3_int64 iOfst)
+{
+    chromiumVfsFile* f = (chromiumVfsFile*)fi;
+    return f->realFile->pMethods->xWrite(f->realFile, pBuf, iAmt, iOfst);
+}
+
+int chromiumTruncate(sqlite3_file* fi, sqlite3_int64 size)
+{
+    chromiumVfsFile* f = (chromiumVfsFile*)fi;
+
+    // The OSX and Linux sandboxes block ftruncate(), proxy to the browser
+    // process.
+    if (Platform::current()->databaseSetFileSize(String(f->fileName), size))
+        return SQLITE_OK;
+    return SQLITE_IOERR_TRUNCATE;
+}
+
+int chromiumSync(sqlite3_file* fi, int flags)
+{
+    chromiumVfsFile* f = (chromiumVfsFile*)fi;
+    return f->realFile->pMethods->xSync(f->realFile, flags);
+}
+
+int chromiumFileSize(sqlite3_file* fi, sqlite3_int64 *pSize)
+{
+    chromiumVfsFile* f = (chromiumVfsFile*)fi;
+    return f->realFile->pMethods->xFileSize(f->realFile, pSize);
+}
+
+int chromiumLock(sqlite3_file* fi, int eFileLock)
+{
+    chromiumVfsFile* f = (chromiumVfsFile*)fi;
+    return f->realFile->pMethods->xLock(f->realFile, eFileLock);
+}
+
+int chromiumUnlock(sqlite3_file* fi, int eFileLock)
+{
+    chromiumVfsFile* f = (chromiumVfsFile*)fi;
+    return f->realFile->pMethods->xUnlock(f->realFile, eFileLock);
+}
+
+int chromiumCheckReservedLock(sqlite3_file* fi, int *pResOut)
+{
+    chromiumVfsFile* f = (chromiumVfsFile*)fi;
+    return f->realFile->pMethods->xCheckReservedLock(f->realFile, pResOut);
+}
+
+int chromiumFileControl(sqlite3_file* fi, int op, void *pArg)
+{
+    chromiumVfsFile* f = (chromiumVfsFile*)fi;
+    return f->realFile->pMethods->xFileControl(f->realFile, op, pArg);
+}
+
+int chromiumSectorSize(sqlite3_file* fi)
+{
+    chromiumVfsFile* f = (chromiumVfsFile*)fi;
+    return f->realFile->pMethods->xSectorSize(f->realFile);
+}
+
+int chromiumDeviceCharacteristics(sqlite3_file* fi)
+{
+    chromiumVfsFile* f = (chromiumVfsFile*)fi;
+    return f->realFile->pMethods->xDeviceCharacteristics(f->realFile);
+}
+
 // Opens a file.
 //
 // vfs - pointer to the sqlite3_vfs object.
@@ -59,8 +146,8 @@ namespace {
 // id - the structure that will manipulate the newly opened file.
 // desiredFlags - the desired open mode flags.
 // usedFlags - the actual open mode flags that were used.
-int chromiumOpen(sqlite3_vfs* vfs, const char* fileName,
-                 sqlite3_file* id, int desiredFlags, int* usedFlags)
+int chromiumOpenInternal(sqlite3_vfs* vfs, const char* fileName,
+                         sqlite3_file* id, int desiredFlags, int* usedFlags)

[Scott Hess - ex-Googler, 2015/03/18 01:45:46]

Still figuring out why this indentation is throwing presubmit complaints, I'll
circle back and fix it.

[michaeln, 2015/03/19 00:14:04]

probably it predates the tool and the checks

[Scott Hess - ex-Googler, 2015/03/25 20:19:55]

Looks like I can just not wrap it...

 {
     chromium_sqlite3_initialize_unix_sqlite3_file(id);
     int fd = -1;
@@ -95,6 +182,61 @@ int chromiumOpen(sqlite3_vfs* vfs, const char* fileName,
     return result;
 }
 
+// SQLite allocates a buffer using szOsFile then calls xOpen() on it.  registerSQLiteVFS() caches the size of the "unix"
+// vfs structure for use by chromiumOpen().
+static size_t szUnixFile = 0;
+
+int chromiumOpen(sqlite3_vfs* vfs, const char* fileName,
+                 sqlite3_file* id, int desiredFlags, int* usedFlags)

[Scott Hess - ex-Googler, 2015/03/18 01:45:46]

This indentation is throwing pre-submit complaints, I don't know why because I
think it's identical to the original version.

+{
+    // registerSQLiteVFS() never happened.
+    if (!szUnixFile)
+        return SQLITE_ERROR;
+
+    sqlite3_file* realFile = (sqlite3_file*)sqlite3_malloc(szUnixFile);
+    if (!realFile)
+        return SQLITE_NOMEM;
+
+    // Make a local copy of the file name.  SQLite's os_unix.c appears to be written to allow caching the pointer passed
+    // in to this function, but that seems brittle.
+    char* realFileName = sqlite3_mprintf("%s", fileName);
+    if (!realFileName) {
+        sqlite3_free(realFile);
+        return SQLITE_NOMEM;
+    }
+
+    // SQLite's unixOpen() makes assumptions about the structure of |fileName|.  Our local copy may not answer those
+    // assumptions correctly.
+    int rc = chromiumOpenInternal(vfs, fileName, realFile, desiredFlags, usedFlags);
+    if (rc != SQLITE_OK) {
+        sqlite3_free(realFileName);
+        sqlite3_free(realFile);
+        return rc;
+    }
+
+    static sqlite3_io_methods chromiumIoMethods = {
+        1,
+        chromiumClose,
+        chromiumRead,
+        chromiumWrite,
+        chromiumTruncate,
+        chromiumSync,
+        chromiumFileSize,
+        chromiumLock,
+        chromiumUnlock,
+        chromiumCheckReservedLock,
+        chromiumFileControl,
+        chromiumSectorSize,
+        chromiumDeviceCharacteristics,
+        // Methods above are valid for version 1.

[michaeln, 2015/03/19 00:14:04]

Looks like the default posix io methods provides the v2 methods for a sharedmem
based locking strategy (but there are quite a few different set of iomethods in
there??)

  int (*xShmMap)(sqlite3_file*, int iPg, int pgsz, int, void volatile**);
  int (*xShmLock)(sqlite3_file*, int offset, int n, int flags);
  void (*xShmBarrier)(sqlite3_file*);
  int (*xShmUnmap)(sqlite3_file*, int deleteFlag);
  /* Methods above are valid for version 2 */

By not having those methods here, are we forcing a different strategy to be
used.

[Scott Hess - ex-Googler, 2015/03/25 20:19:55]

My understanding is that the version-2 bits are for write-ahead-logging to
implement a shared-memory log index.  This would need someone to run "PRAGMA
journal_mode = WAL", which is forbidden in the renderer, so I think that's safe.

The version-3 bits are for a memory-mapped access pattern.  I _think_ the
unixFile things which key off of that can only happen if xFetch() is called, so
since we don't implement that, we should be fine.

I posed a new CL to land before this which makes all of the existing sqlite3_vfs
methods proxied.  I think that with that change, the different levels can work
right in isolation without having to worry about whether we're crossing the
streams incorrectly.

+    };
+    chromiumVfsFile* f = (chromiumVfsFile*)id;
+    f->pMethods = &chromiumIoMethods;
+    f->realFile = realFile;
+    f->fileName = realFileName;
+    return SQLITE_OK;
+}
+
 // Deletes the given file.
 //
 // vfs - pointer to the sqlite3_vfs object.
@@ -169,9 +311,10 @@ void* chromiumDlOpen(sqlite3_vfs*, const char*)
 void SQLiteFileSystem::registerSQLiteVFS()
 {
     sqlite3_vfs* unix_vfs = sqlite3_vfs_find("unix");
+    szUnixFile = unix_vfs->szOsFile;
     static sqlite3_vfs chromium_vfs = {
         1,
-        unix_vfs->szOsFile,
+        sizeof(chromiumVfsFile),
         unix_vfs->mxPathname,
         0,
         "chromium_vfs",