urlclassifier3.sqlite is the file that Firefox (as of version 3) uses to store information about websites that are known to host Phishing and/or malware. The data is regularly updated from Google. As typing ‘urlclassifier3.sqlite’ in to Google and spending a few minutes looking through the results will show, It can be something of a problem file. The main complaint is it can grow quite large. This can be especially problematic in environments where users have a quota applied to their home directory. All of the users of machines I manage have quotas applied to their home directories and in the case of those with the smallest quotas the urlclassifier3.sqlite can easily end up using 50% of it. This is of course a problematic situation but the size of the quotas is sadly beyond my control. Unfortunately Firefox provides no method to relocate the file.
The most obvious and easiest way to deal with urlclassifier3.sqlite is to simply get rid of it. Edit > Preferences > Security, un-tick the options ‘Block reported attack sites’ and ‘Block reported web forgeries’. Then delete the urlclassifier3.sqlite file. It would be possible to enforce this setting for all users, but I don’t consider it an acceptable solution since it could potentially result in a user becoming the victim of something which Firefox would have warned them about had I not disabled the mechanism that warned them.
There is however another solution, at least on Linux, and that is to replace the file with symbolic link. The first thing I tried was moving urlclassifer3.sqlite file from my profile to the local hard disk and then creating a symbolic link to it. However this resulted in Firefox replacing the symbolic link with a new copy of urlclassifier3.sqlite. What does achieve the desired effect is creating the symbolic link so that it points at a non-existent file. Firefox then creates the urlclassifier3.sqlite file at the location the symbolic link points at. If you make the symbolic link point somewhere outside the user’s home directory, urlclassifier3.sqlite no longer counts towards the user’s precious quota.
It’s not quite that simple of course. You can’t expect users to do this themselves. So to make this a practical solution you have to automate it. This can be done by creating a suitable script and saving it as /usr/local/bin/firefox (Don’t forget to make it globally readable/executable!) Since /usr/local/bin comes before /usr/bin in $PATH by default, when a user runs Firefox they will actually be running /usr/local/bin/firefox. The Firefox .deskop file (/usr/share/applications/MozillaFirefox.desktop) does not call firefox via an absolute path so /usr/local/bin/firefox is used even if Firefox is launched via the GNOME/KDE menu. The /usr/local/bin/firefox script is attached to this article along with another script which it makes use. The second script locates the user’s Firefox profile directory and I blogged about it here: http://blogs.warwick.ac.uk/mikewillis/entry/finding_the_path/
The script is written with the concept of a predictable resource location denial of service attacks in mind. Simply speaking this means you should not make the symbolic link point somewhere predictable on the local disk in case a malicious user decides to create a file at the location where the symbolic link would point for another user or users. That’s easily taken care of though by using mktemp to create a directory with an unpredictable name in which the urlclassifier3.sqlite is then created.
The script also removes urlclassifier2.sqlite from the Firefox profile directory if it exists. This file is the Firefox 2 equivalent of urlclassifier3.sqlite and I’ve found it remains longer after one has started using Firefox 3 despite no longer being used.
One issue with relocating urlclassifier3.sqlite in this manner is that it means that each time the user runs Firefox their urlclassifier3.sqlite is recreated again from scratch and so they are, in theory at least, vulnerable to what the file is designed to protect them against until such time as Firefox downloads data to populate it. However this situation occurs when someone runs Firefox for the very first time and I consider the risk acceptable given than the benefits of relocating the file.