Fix WebSQL error on sandboxed OSX and Linux.

Source/modules/webdatabase/sqlite/SQLiteFileSystemPosix.cpp

 /*
  * Copyright (C) 2009 Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
  *     * Redistributions in binary form must reproduce the above
@@ skipping 34 matching lines @@
 int chromium_sqlite3_get_reusable_file_handle(sqlite3_file* file, const char* fileName, int flags, int* fd);
 void chromium_sqlite3_update_reusable_file_handle(sqlite3_file* file, int fd, int flags);
 void chromium_sqlite3_destroy_reusable_file_handle(sqlite3_file* file);
 }
 
 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.
 // fileName - the name of the file.
 // 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;
     int result = chromium_sqlite3_get_reusable_file_handle(id, fileName, desiredFlags, &fd);
     if (result != SQLITE_OK)
         return result;
 
     if (fd < 0) {
         fd = Platform::current()->databaseOpenFile(String(fileName), desiredFlags);
         if ((fd < 0) && (desiredFlags & SQLITE_OPEN_READWRITE)) {
@@ skipping 14 matching lines @@
 
     // The mask 0x00007F00 gives us the 7 bits that determine the type of the file SQLite is trying to open.
     int fileType = desiredFlags & 0x00007F00;
     int noLock = (fileType != SQLITE_OPEN_MAIN_DB);
     result = chromium_sqlite3_fill_in_unix_sqlite3_file(vfs, fd, -1, id, fileName, noLock);
     if (result != SQLITE_OK)
         chromium_sqlite3_destroy_reusable_file_handle(id);
     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.
 // fileName - the name of the file.
 // syncDir - determines if the directory to which this file belongs
 //           should be synched after the file is deleted.
 int chromiumDelete(sqlite3_vfs*, const char* fileName, int syncDir)
 {
     return Platform::current()->databaseDeleteFile(String(fileName), syncDir);
 }
@@ skipping 54 matching lines @@
 }
 #else
 #define chromiumDlOpen 0
 #endif // SQLITE_OMIT_LOAD_EXTENSION
 
 } // namespace
 
 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",
         unix_vfs->pAppData,

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

this func ptr is supposed to be a FINDER function

  ** Most finders simply return a pointer to a fixed sqlite3_io_methods
  ** object.  But the "autolockIoFinder" available on MacOSX does a little
  ** more than that; it looks at the filesystem type that hosts the 
  ** database file and tries to choose an locking method appropriate for
  ** that filesystem time.

should we have a func ptr here that returns chromiumIoMethods?

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

pAppData is just a place you can tuck random information into the structure. 
As-is chromium_vfs is pretty incorrect because those directly-inherited methods
could potentially have implicit expectations about the form of this structure. 
Only unixOpen() actually uses it, so we've been lucky, but better to just proxy
everything.

As a bonus, proxying with the wrapped vfs in pAppData will remove the need for
szUnixFile global.

         chromiumOpen,
         chromiumDelete,
         chromiumAccess,
         chromiumFullPathname,
         chromiumDlOpen,
         unix_vfs->xDlError,
         unix_vfs->xDlSym,
         unix_vfs->xDlClose,
         unix_vfs->xRandomness,
         unix_vfs->xSleep,
         unix_vfs->xCurrentTime,
         unix_vfs->xGetLastError
     };
     sqlite3_vfs_register(&chromium_vfs, 0);
 }
 
 } // namespace blink