On 2016/01/11 9:37 PM, Warren Young wrote: > 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.
There is nothing preventing a rogue anything from adding data to your file, even after your Schema exists. Why would it need this condition to "help" it? Also, if you save passwords without encryption with proper SALTs etc, then worrying about the above is the least of your concerns. I think the OP really means simply other processes from their own system(s) doing a bit of jiggery-pokery when finding an un-made schema - but I could be wrong.
