|
|
|
|
Mandatory File Locking For The Linux Operating System Andy Walker 15 April 1996 (Updated September 2007) 0\. Why you should avoid mandatory locking \----------------------------------------- The Linux implementation is prey to a number of difficult-to-fix race conditions which in practice make it not dependable: \- The write system call checks for a mandatory lock only once at its start. It is therefore possible for a lock request to be granted after this check but before the data is modified. A process may then see file data change even while a mandatory lock was held. \- Similarly, an exclusive lock may be granted on a file after the kernel has decided to proceed with a read, but before the read has actually completed, and the reading process may see the file data in a state which should not have been visible to it. \- Similar races make the claimed mutual exclusion between lock and mmap similarly unreliable. 1\. What is mandatory locking? \------------------------------ Mandatory locking is kernel enforced file locking, as opposed to the more usual cooperative file locking used to guarantee sequential access to files among processes. File locks are applied using the flock() and fcntl() system calls (and the lockf() library routine which is a wrapper around fcntl().) It is normally a process' responsibility to check for locks on a file it wishes to update, before applying its own lock, updating the file and unlocking it again. The most commonly used example of this (and in the case of sendmail, the most troublesome) is access to a user's mailbox. The mail user agent and the mail transfer agent must guard against updating the mailbox at the same time, and prevent reading the mailbox while it is being updated. In a perfect world all processes would use and honour a cooperative, or "advisory" locking scheme. However, the world isn't perfect, and there's a lot of poorly written code out there. In trying to address this problem, the designers of System V UNIX came up with a "mandatory" locking scheme, whereby the operating system kernel would block attempts by a process to write to a file that another process holds a "read" -or- "shared" lock on, and block attempts to both read and write to a file that a process holds a "write " -or- "exclusive" lock on. The System V mandatory locking scheme was intended to have as little impact as possible on existing user code. The scheme is based on marking individual files as candidates for mandatory locking, and using the existing fcntl()/lockf() interface for applying locks just as if they were normal, advisory locks. Note 1: In saying "file" in the paragraphs above I am actually not telling the whole truth. System V locking is based on fcntl(). The granularity of fcntl() is such that it allows the locking of byte ranges in files, in addition to entire files, so the mandatory locking rules also have byte level granularity. Note 2: POSIX.1 does not specify any scheme for mandatory locking, despite borrowing the fcntl() locking scheme from System V. The mandatory locking scheme is defined by the System V Interface Definition (SVID) Version 3. 2\. Marking a file for mandatory locking \--------------------------------------- A file is marked as a candidate for mandatory locking by setting the group-id bit in its file mode but removing the group-execute bit. This is an otherwise meaningless combination, and was chosen by the System V implementors so as not to break existing user programs. Note that the group-id bit is usually automatically cleared by the kernel when a setgid file is written to. This is a security measure. The kernel has been modified to recognize the special case of a mandatory lock candidate and to refrain from clearing this bit. Similarly the kernel has been modified not to run mandatory lock candidates with setgid privileges. 3\. Available implementations \---------------------------- I have considered the implementations of mandatory locking available with SunOS 4.1.x, Solaris 2.x and HP-UX 9.x. Generally I have tried to make the most sense out of the behaviour exhib
|
