Root/
1 | Mandatory File Locking For The Linux Operating System |
2 | |
3 | Andy Walker <andy@lysaker.kvaerner.no> |
4 | |
5 | 15 April 1996 |
6 | (Updated September 2007) |
7 | |
8 | 0. Why you should avoid mandatory locking |
9 | ----------------------------------------- |
10 | |
11 | The Linux implementation is prey to a number of difficult-to-fix race |
12 | conditions which in practice make it not dependable: |
13 | |
14 | - The write system call checks for a mandatory lock only once |
15 | at its start. It is therefore possible for a lock request to |
16 | be granted after this check but before the data is modified. |
17 | A process may then see file data change even while a mandatory |
18 | lock was held. |
19 | - Similarly, an exclusive lock may be granted on a file after |
20 | the kernel has decided to proceed with a read, but before the |
21 | read has actually completed, and the reading process may see |
22 | the file data in a state which should not have been visible |
23 | to it. |
24 | - Similar races make the claimed mutual exclusion between lock |
25 | and mmap similarly unreliable. |
26 | |
27 | 1. What is mandatory locking? |
28 | ------------------------------ |
29 | |
30 | Mandatory locking is kernel enforced file locking, as opposed to the more usual |
31 | cooperative file locking used to guarantee sequential access to files among |
32 | processes. File locks are applied using the flock() and fcntl() system calls |
33 | (and the lockf() library routine which is a wrapper around fcntl().) It is |
34 | normally a process' responsibility to check for locks on a file it wishes to |
35 | update, before applying its own lock, updating the file and unlocking it again. |
36 | The most commonly used example of this (and in the case of sendmail, the most |
37 | troublesome) is access to a user's mailbox. The mail user agent and the mail |
38 | transfer agent must guard against updating the mailbox at the same time, and |
39 | prevent reading the mailbox while it is being updated. |
40 | |
41 | In a perfect world all processes would use and honour a cooperative, or |
42 | "advisory" locking scheme. However, the world isn't perfect, and there's |
43 | a lot of poorly written code out there. |
44 | |
45 | In trying to address this problem, the designers of System V UNIX came up |
46 | with a "mandatory" locking scheme, whereby the operating system kernel would |
47 | block attempts by a process to write to a file that another process holds a |
48 | "read" -or- "shared" lock on, and block attempts to both read and write to a |
49 | file that a process holds a "write " -or- "exclusive" lock on. |
50 | |
51 | The System V mandatory locking scheme was intended to have as little impact as |
52 | possible on existing user code. The scheme is based on marking individual files |
53 | as candidates for mandatory locking, and using the existing fcntl()/lockf() |
54 | interface for applying locks just as if they were normal, advisory locks. |
55 | |
56 | Note 1: In saying "file" in the paragraphs above I am actually not telling |
57 | the whole truth. System V locking is based on fcntl(). The granularity of |
58 | fcntl() is such that it allows the locking of byte ranges in files, in addition |
59 | to entire files, so the mandatory locking rules also have byte level |
60 | granularity. |
61 | |
62 | Note 2: POSIX.1 does not specify any scheme for mandatory locking, despite |
63 | borrowing the fcntl() locking scheme from System V. The mandatory locking |
64 | scheme is defined by the System V Interface Definition (SVID) Version 3. |
65 | |
66 | 2. Marking a file for mandatory locking |
67 | --------------------------------------- |
68 | |
69 | A file is marked as a candidate for mandatory locking by setting the group-id |
70 | bit in its file mode but removing the group-execute bit. This is an otherwise |
71 | meaningless combination, and was chosen by the System V implementors so as not |
72 | to break existing user programs. |
73 | |
74 | Note that the group-id bit is usually automatically cleared by the kernel when |
75 | a setgid file is written to. This is a security measure. The kernel has been |
76 | modified to recognize the special case of a mandatory lock candidate and to |
77 | refrain from clearing this bit. Similarly the kernel has been modified not |
78 | to run mandatory lock candidates with setgid privileges. |
79 | |
80 | 3. Available implementations |
81 | ---------------------------- |
82 | |
83 | I have considered the implementations of mandatory locking available with |
84 | SunOS 4.1.x, Solaris 2.x and HP-UX 9.x. |
85 | |
86 | Generally I have tried to make the most sense out of the behaviour exhibited |
87 | by these three reference systems. There are many anomalies. |
88 | |
89 | All the reference systems reject all calls to open() for a file on which |
90 | another process has outstanding mandatory locks. This is in direct |
91 | contravention of SVID 3, which states that only calls to open() with the |
92 | O_TRUNC flag set should be rejected. The Linux implementation follows the SVID |
93 | definition, which is the "Right Thing", since only calls with O_TRUNC can |
94 | modify the contents of the file. |
95 | |
96 | HP-UX even disallows open() with O_TRUNC for a file with advisory locks, not |
97 | just mandatory locks. That would appear to contravene POSIX.1. |
98 | |
99 | mmap() is another interesting case. All the operating systems mentioned |
100 | prevent mandatory locks from being applied to an mmap()'ed file, but HP-UX |
101 | also disallows advisory locks for such a file. SVID actually specifies the |
102 | paranoid HP-UX behaviour. |
103 | |
104 | In my opinion only MAP_SHARED mappings should be immune from locking, and then |
105 | only from mandatory locks - that is what is currently implemented. |
106 | |
107 | SunOS is so hopeless that it doesn't even honour the O_NONBLOCK flag for |
108 | mandatory locks, so reads and writes to locked files always block when they |
109 | should return EAGAIN. |
110 | |
111 | I'm afraid that this is such an esoteric area that the semantics described |
112 | below are just as valid as any others, so long as the main points seem to |
113 | agree. |
114 | |
115 | 4. Semantics |
116 | ------------ |
117 | |
118 | 1. Mandatory locks can only be applied via the fcntl()/lockf() locking |
119 | interface - in other words the System V/POSIX interface. BSD style |
120 | locks using flock() never result in a mandatory lock. |
121 | |
122 | 2. If a process has locked a region of a file with a mandatory read lock, then |
123 | other processes are permitted to read from that region. If any of these |
124 | processes attempts to write to the region it will block until the lock is |
125 | released, unless the process has opened the file with the O_NONBLOCK |
126 | flag in which case the system call will return immediately with the error |
127 | status EAGAIN. |
128 | |
129 | 3. If a process has locked a region of a file with a mandatory write lock, all |
130 | attempts to read or write to that region block until the lock is released, |
131 | unless a process has opened the file with the O_NONBLOCK flag in which case |
132 | the system call will return immediately with the error status EAGAIN. |
133 | |
134 | 4. Calls to open() with O_TRUNC, or to creat(), on a existing file that has |
135 | any mandatory locks owned by other processes will be rejected with the |
136 | error status EAGAIN. |
137 | |
138 | 5. Attempts to apply a mandatory lock to a file that is memory mapped and |
139 | shared (via mmap() with MAP_SHARED) will be rejected with the error status |
140 | EAGAIN. |
141 | |
142 | 6. Attempts to create a shared memory map of a file (via mmap() with MAP_SHARED) |
143 | that has any mandatory locks in effect will be rejected with the error status |
144 | EAGAIN. |
145 | |
146 | 5. Which system calls are affected? |
147 | ----------------------------------- |
148 | |
149 | Those which modify a file's contents, not just the inode. That gives read(), |
150 | write(), readv(), writev(), open(), creat(), mmap(), truncate() and |
151 | ftruncate(). truncate() and ftruncate() are considered to be "write" actions |
152 | for the purposes of mandatory locking. |
153 | |
154 | The affected region is usually defined as stretching from the current position |
155 | for the total number of bytes read or written. For the truncate calls it is |
156 | defined as the bytes of a file removed or added (we must also consider bytes |
157 | added, as a lock can specify just "the whole file", rather than a specific |
158 | range of bytes.) |
159 | |
160 | Note 3: I may have overlooked some system calls that need mandatory lock |
161 | checking in my eagerness to get this code out the door. Please let me know, or |
162 | better still fix the system calls yourself and submit a patch to me or Linus. |
163 | |
164 | 6. Warning! |
165 | ----------- |
166 | |
167 | Not even root can override a mandatory lock, so runaway processes can wreak |
168 | havoc if they lock crucial files. The way around it is to change the file |
169 | permissions (remove the setgid bit) before trying to read or write to it. |
170 | Of course, that might be a bit tricky if the system is hung :-( |
171 | |
172 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9