On 04/08/2015 09:51 PM, R.Smith wrote: > > > On 2015-04-08 04:18 PM, Fabian Pr?bstl wrote: >> Hi there! >> >> Currently, we are using SQLite as our application file format for a >> Windows 7/C#/System.Data.SQLite based desktop application. We only >> allow one instance to open the file by running "set >> locking_mode=EXCLUSIVE;BEGIN EXCLUSIVE;COMMIT" when connecting to the >> database. > > BEGIN EXCLUSIVE - Locks the database from other SQLite3 database > connections for the time being. > COMMIT; - Unlocks it again - so calling all this in one go is pointless.
Almost always correct. But the "PRAGMA locking_mode=EXCLUSIVE" thing changes the behaviour: https://www.sqlite.org/pragma.html#pragma_locking_mode > > That said, database locking serves only to protect from other database > changes... There is no way to prevent a user from intentional messing > with any file if they have the privileges to do so. Best practice is > to keep the file in your program's assigned /programdata folder or the > user folders (/AppData/Roaming/yourApp/ is the usual) - the typical > user won't go mess there or even know to look there. Other than that, > the entire point of an operating system is to serve its user, not your > program - as it should, so you cannot unfortunately protect users > against themselves. > > If this is to do with your own security being a concern (i.e. you are > not trying to safeguard the user) then I would strongly suggest an > encryption module or using a DB with user-level locking. (Even then > you still won't be able to protect against a willful user deleting, > moving, overwriting or otherwise accessing a file). > > At a tangent: > How would you feel if your operating system disallowed you those > privileges because some program you installed asked it to? I would > change operating systems immediately - Viruses are a big enough > problem as it is - imagine being unable to get rid of them... > > Good luck! > Ryan > > >> >> This all works fine, however a user can still open Windows Explorer >> and copy paste a file with the same name but different content (e.g. >> an empty file) over an existing, exclusively locked database. From >> what I found out with the OpenedFilesView tool, SQLite seems to open >> the file with SHARED_WRITE, which explains why *any* process can >> overwrite the contents. >> >> Is there an easy way of configuring / changing this so that >> SHARED_WRITE is not acquired? Will SQLite even function? Is it just >> easier to create a hidden copy and work on that? >> >> Thanks for the advice >> Fabian >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users at mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
