File permissions on database files created by the library libsqlite3 on Unix/Linux are created with a mask setting that restricts permissions beyond what the user may expect from the current umask setting.
In the file src/os_unix.c a mask is defined as: ** Default permissions when creating a new file */ #ifndef SQLITE_DEFAULT_FILE_PERMISSIONS # define SQLITE_DEFAULT_FILE_PERMISSIONS 0644 #endif which is applied when the open function is called to open a database and create it if necessary. In many cases the user has umask settings 022 and new files are thus created with 644 permissions which are what the user expects. However, if the user has an umask setting of 002, to allow write permissions for the group by giving newly created files permissions as 664, the mask defined in the sqlite source code restricts this to 644 nevertheless, as the default file permission defined above is a value for masking the permissions. IMHO this is an error. A valid example of that are on server machines where web services such as Trac are provided. If several administrators work together such machines are often configured so that the SGD bit is set on the directories where Trac-webs are stored, and the group for them are set to the user name that runs the web-server. On Debian/Ubuntu systems that is www-data. The intention of this is to allow the web-server to write in the database file, but also to allow an administrator to do administration such as deleting a file created by another administrator. With Subversion 1.6 there is an essentially identical problem arising as sqlite3 is used within Subversion repositories in the form of the file db/rep-cache.db. This file is created when something is put in the repository and not when the repository is created (with svnadmin create). Thus everything looks fine and files and directories have the correct permissions in a newly created repository. But, the database file that is created when something is put into the repository may not be writable by the web-server process, as it will have 644 permissions, and the web-server process will then report an error. A work-around for this is to create an empty database file (e.g. by touch) and give it correct permissions (664). But it is clearly tedious and error prone to depend on this type of extra tasks for something that should be done correctly in the first place. This problem is reported as Debian bug #608604, but it has come to my attention that other distributions are also bitten by this and it is probably best fixed upstream. I have searched the sqlite archives and this topic sometimes surfaces, the most recent mentioning seems to be on Jan 10, 2011: http://comments.gmane.org/gmane.comp.db.sqlite.general/62194 Another thread is started by http://article.gmane.org/gmane.comp.db.sqlite.general/26395 where some posts indicate a full understanding of the problem. In summary, I'd like to report this as a bug. A trivial fix exists which does not change the behaviour for most users but does help in a common situation where many people cooperate on administrating important production servers on which sqlite databases are used. Anders _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
