On Jan 11, 2016, at 12:27 PM, Simon Slavin <slavins at bigfraud.org> wrote: > > On 11 Jan 2016, at 7:06pm, Warren Young <wyml at etr-usa.com> wrote: > >> On Jan 11, 2016, at 11:57 AM, Simon Slavin <slavins at bigfraud.org> wrote: >> >>> Just do BEGIN IMMEDIATE immediately after you open the database. >> >> Doesn?t that set up a race condition? What prevents the other process from >> opening the DB and running its own SQL if the OS?s scheduler happens to take >> the CPU away from the legitimate process between sqlite3_open_v2() and >> sqlite3_exec(?, ?BEGIN IMMEDIATE?, ?) ? > > Okay, so your concern is that the other process intrudes between the _open() > and the BEGIN. > > If that's the case then I suggest that you create your new database > (including schema and any initial data) with a different filename. Then once > this is complete, close it (as far as SQLite is concerned) then use your OS > calls to rename the file to whatever your database is normally called.
Which is what I suggested with my mkstemp(3) solution. I neglected to say that you should close the DB file before moving it, though, so I guess it?s good to have it restated. Another previously unstated detail is that you can leave the mkstemp-created file permissions alone until after your process has moved and re-opened the database. That lets your process do further modifications to the DB before calling chmod on it to allow other users? processes access to it. > My question is what the other process does. The OP was vague about that, but I think the point of his current gymnastics is to prevent the other process from creating a rogue schema, or to insert compromising data into a correct schema. To make it concrete, you could probably write a black hat process that could get in between the creation of a new Fossil DB file and the initial schema setup, then add an all-powerful Admin user with a known password. When the fossil binary regains control from the OS, it will see that the ?users? table already exists, so it won?t install its own, leaving the DB file backdoored. That?s why you have to use something like mkstemp() to create the DB file somewhere only your process can see it, and with permissions that allow only your user to open or modify it.
