Root/
1 | Definitions |
2 | ~~~~~~~~~~~ |
3 | |
4 | Userspace filesystem: |
5 | |
6 | A filesystem in which data and metadata are provided by an ordinary |
7 | userspace process. The filesystem can be accessed normally through |
8 | the kernel interface. |
9 | |
10 | Filesystem daemon: |
11 | |
12 | The process(es) providing the data and metadata of the filesystem. |
13 | |
14 | Non-privileged mount (or user mount): |
15 | |
16 | A userspace filesystem mounted by a non-privileged (non-root) user. |
17 | The filesystem daemon is running with the privileges of the mounting |
18 | user. NOTE: this is not the same as mounts allowed with the "user" |
19 | option in /etc/fstab, which is not discussed here. |
20 | |
21 | Filesystem connection: |
22 | |
23 | A connection between the filesystem daemon and the kernel. The |
24 | connection exists until either the daemon dies, or the filesystem is |
25 | umounted. Note that detaching (or lazy umounting) the filesystem |
26 | does _not_ break the connection, in this case it will exist until |
27 | the last reference to the filesystem is released. |
28 | |
29 | Mount owner: |
30 | |
31 | The user who does the mounting. |
32 | |
33 | User: |
34 | |
35 | The user who is performing filesystem operations. |
36 | |
37 | What is FUSE? |
38 | ~~~~~~~~~~~~~ |
39 | |
40 | FUSE is a userspace filesystem framework. It consists of a kernel |
41 | module (fuse.ko), a userspace library (libfuse.*) and a mount utility |
42 | (fusermount). |
43 | |
44 | One of the most important features of FUSE is allowing secure, |
45 | non-privileged mounts. This opens up new possibilities for the use of |
46 | filesystems. A good example is sshfs: a secure network filesystem |
47 | using the sftp protocol. |
48 | |
49 | The userspace library and utilities are available from the FUSE |
50 | homepage: |
51 | |
52 | http://fuse.sourceforge.net/ |
53 | |
54 | Filesystem type |
55 | ~~~~~~~~~~~~~~~ |
56 | |
57 | The filesystem type given to mount(2) can be one of the following: |
58 | |
59 | 'fuse' |
60 | |
61 | This is the usual way to mount a FUSE filesystem. The first |
62 | argument of the mount system call may contain an arbitrary string, |
63 | which is not interpreted by the kernel. |
64 | |
65 | 'fuseblk' |
66 | |
67 | The filesystem is block device based. The first argument of the |
68 | mount system call is interpreted as the name of the device. |
69 | |
70 | Mount options |
71 | ~~~~~~~~~~~~~ |
72 | |
73 | 'fd=N' |
74 | |
75 | The file descriptor to use for communication between the userspace |
76 | filesystem and the kernel. The file descriptor must have been |
77 | obtained by opening the FUSE device ('/dev/fuse'). |
78 | |
79 | 'rootmode=M' |
80 | |
81 | The file mode of the filesystem's root in octal representation. |
82 | |
83 | 'user_id=N' |
84 | |
85 | The numeric user id of the mount owner. |
86 | |
87 | 'group_id=N' |
88 | |
89 | The numeric group id of the mount owner. |
90 | |
91 | 'default_permissions' |
92 | |
93 | By default FUSE doesn't check file access permissions, the |
94 | filesystem is free to implement it's access policy or leave it to |
95 | the underlying file access mechanism (e.g. in case of network |
96 | filesystems). This option enables permission checking, restricting |
97 | access based on file mode. It is usually useful together with the |
98 | 'allow_other' mount option. |
99 | |
100 | 'allow_other' |
101 | |
102 | This option overrides the security measure restricting file access |
103 | to the user mounting the filesystem. This option is by default only |
104 | allowed to root, but this restriction can be removed with a |
105 | (userspace) configuration option. |
106 | |
107 | 'max_read=N' |
108 | |
109 | With this option the maximum size of read operations can be set. |
110 | The default is infinite. Note that the size of read requests is |
111 | limited anyway to 32 pages (which is 128kbyte on i386). |
112 | |
113 | 'blksize=N' |
114 | |
115 | Set the block size for the filesystem. The default is 512. This |
116 | option is only valid for 'fuseblk' type mounts. |
117 | |
118 | Control filesystem |
119 | ~~~~~~~~~~~~~~~~~~ |
120 | |
121 | There's a control filesystem for FUSE, which can be mounted by: |
122 | |
123 | mount -t fusectl none /sys/fs/fuse/connections |
124 | |
125 | Mounting it under the '/sys/fs/fuse/connections' directory makes it |
126 | backwards compatible with earlier versions. |
127 | |
128 | Under the fuse control filesystem each connection has a directory |
129 | named by a unique number. |
130 | |
131 | For each connection the following files exist within this directory: |
132 | |
133 | 'waiting' |
134 | |
135 | The number of requests which are waiting to be transferred to |
136 | userspace or being processed by the filesystem daemon. If there is |
137 | no filesystem activity and 'waiting' is non-zero, then the |
138 | filesystem is hung or deadlocked. |
139 | |
140 | 'abort' |
141 | |
142 | Writing anything into this file will abort the filesystem |
143 | connection. This means that all waiting requests will be aborted an |
144 | error returned for all aborted and new requests. |
145 | |
146 | Only the owner of the mount may read or write these files. |
147 | |
148 | Interrupting filesystem operations |
149 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
150 | |
151 | If a process issuing a FUSE filesystem request is interrupted, the |
152 | following will happen: |
153 | |
154 | 1) If the request is not yet sent to userspace AND the signal is |
155 | fatal (SIGKILL or unhandled fatal signal), then the request is |
156 | dequeued and returns immediately. |
157 | |
158 | 2) If the request is not yet sent to userspace AND the signal is not |
159 | fatal, then an 'interrupted' flag is set for the request. When |
160 | the request has been successfully transferred to userspace and |
161 | this flag is set, an INTERRUPT request is queued. |
162 | |
163 | 3) If the request is already sent to userspace, then an INTERRUPT |
164 | request is queued. |
165 | |
166 | INTERRUPT requests take precedence over other requests, so the |
167 | userspace filesystem will receive queued INTERRUPTs before any others. |
168 | |
169 | The userspace filesystem may ignore the INTERRUPT requests entirely, |
170 | or may honor them by sending a reply to the _original_ request, with |
171 | the error set to EINTR. |
172 | |
173 | It is also possible that there's a race between processing the |
174 | original request and it's INTERRUPT request. There are two possibilities: |
175 | |
176 | 1) The INTERRUPT request is processed before the original request is |
177 | processed |
178 | |
179 | 2) The INTERRUPT request is processed after the original request has |
180 | been answered |
181 | |
182 | If the filesystem cannot find the original request, it should wait for |
183 | some timeout and/or a number of new requests to arrive, after which it |
184 | should reply to the INTERRUPT request with an EAGAIN error. In case |
185 | 1) the INTERRUPT request will be requeued. In case 2) the INTERRUPT |
186 | reply will be ignored. |
187 | |
188 | Aborting a filesystem connection |
189 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
190 | |
191 | It is possible to get into certain situations where the filesystem is |
192 | not responding. Reasons for this may be: |
193 | |
194 | a) Broken userspace filesystem implementation |
195 | |
196 | b) Network connection down |
197 | |
198 | c) Accidental deadlock |
199 | |
200 | d) Malicious deadlock |
201 | |
202 | (For more on c) and d) see later sections) |
203 | |
204 | In either of these cases it may be useful to abort the connection to |
205 | the filesystem. There are several ways to do this: |
206 | |
207 | - Kill the filesystem daemon. Works in case of a) and b) |
208 | |
209 | - Kill the filesystem daemon and all users of the filesystem. Works |
210 | in all cases except some malicious deadlocks |
211 | |
212 | - Use forced umount (umount -f). Works in all cases but only if |
213 | filesystem is still attached (it hasn't been lazy unmounted) |
214 | |
215 | - Abort filesystem through the FUSE control filesystem. Most |
216 | powerful method, always works. |
217 | |
218 | How do non-privileged mounts work? |
219 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
220 | |
221 | Since the mount() system call is a privileged operation, a helper |
222 | program (fusermount) is needed, which is installed setuid root. |
223 | |
224 | The implication of providing non-privileged mounts is that the mount |
225 | owner must not be able to use this capability to compromise the |
226 | system. Obvious requirements arising from this are: |
227 | |
228 | A) mount owner should not be able to get elevated privileges with the |
229 | help of the mounted filesystem |
230 | |
231 | B) mount owner should not get illegitimate access to information from |
232 | other users' and the super user's processes |
233 | |
234 | C) mount owner should not be able to induce undesired behavior in |
235 | other users' or the super user's processes |
236 | |
237 | How are requirements fulfilled? |
238 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
239 | |
240 | A) The mount owner could gain elevated privileges by either: |
241 | |
242 | 1) creating a filesystem containing a device file, then opening |
243 | this device |
244 | |
245 | 2) creating a filesystem containing a suid or sgid application, |
246 | then executing this application |
247 | |
248 | The solution is not to allow opening device files and ignore |
249 | setuid and setgid bits when executing programs. To ensure this |
250 | fusermount always adds "nosuid" and "nodev" to the mount options |
251 | for non-privileged mounts. |
252 | |
253 | B) If another user is accessing files or directories in the |
254 | filesystem, the filesystem daemon serving requests can record the |
255 | exact sequence and timing of operations performed. This |
256 | information is otherwise inaccessible to the mount owner, so this |
257 | counts as an information leak. |
258 | |
259 | The solution to this problem will be presented in point 2) of C). |
260 | |
261 | C) There are several ways in which the mount owner can induce |
262 | undesired behavior in other users' processes, such as: |
263 | |
264 | 1) mounting a filesystem over a file or directory which the mount |
265 | owner could otherwise not be able to modify (or could only |
266 | make limited modifications). |
267 | |
268 | This is solved in fusermount, by checking the access |
269 | permissions on the mountpoint and only allowing the mount if |
270 | the mount owner can do unlimited modification (has write |
271 | access to the mountpoint, and mountpoint is not a "sticky" |
272 | directory) |
273 | |
274 | 2) Even if 1) is solved the mount owner can change the behavior |
275 | of other users' processes. |
276 | |
277 | i) It can slow down or indefinitely delay the execution of a |
278 | filesystem operation creating a DoS against the user or the |
279 | whole system. For example a suid application locking a |
280 | system file, and then accessing a file on the mount owner's |
281 | filesystem could be stopped, and thus causing the system |
282 | file to be locked forever. |
283 | |
284 | ii) It can present files or directories of unlimited length, or |
285 | directory structures of unlimited depth, possibly causing a |
286 | system process to eat up diskspace, memory or other |
287 | resources, again causing DoS. |
288 | |
289 | The solution to this as well as B) is not to allow processes |
290 | to access the filesystem, which could otherwise not be |
291 | monitored or manipulated by the mount owner. Since if the |
292 | mount owner can ptrace a process, it can do all of the above |
293 | without using a FUSE mount, the same criteria as used in |
294 | ptrace can be used to check if a process is allowed to access |
295 | the filesystem or not. |
296 | |
297 | Note that the ptrace check is not strictly necessary to |
298 | prevent B/2/i, it is enough to check if mount owner has enough |
299 | privilege to send signal to the process accessing the |
300 | filesystem, since SIGSTOP can be used to get a similar effect. |
301 | |
302 | I think these limitations are unacceptable? |
303 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
304 | |
305 | If a sysadmin trusts the users enough, or can ensure through other |
306 | measures, that system processes will never enter non-privileged |
307 | mounts, it can relax the last limitation with a "user_allow_other" |
308 | config option. If this config option is set, the mounting user can |
309 | add the "allow_other" mount option which disables the check for other |
310 | users' processes. |
311 | |
312 | Kernel - userspace interface |
313 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
314 | |
315 | The following diagram shows how a filesystem operation (in this |
316 | example unlink) is performed in FUSE. |
317 | |
318 | NOTE: everything in this description is greatly simplified |
319 | |
320 | | "rm /mnt/fuse/file" | FUSE filesystem daemon |
321 | | | |
322 | | | >sys_read() |
323 | | | >fuse_dev_read() |
324 | | | >request_wait() |
325 | | | [sleep on fc->waitq] |
326 | | | |
327 | | >sys_unlink() | |
328 | | >fuse_unlink() | |
329 | | [get request from | |
330 | | fc->unused_list] | |
331 | | >request_send() | |
332 | | [queue req on fc->pending] | |
333 | | [wake up fc->waitq] | [woken up] |
334 | | >request_wait_answer() | |
335 | | [sleep on req->waitq] | |
336 | | | <request_wait() |
337 | | | [remove req from fc->pending] |
338 | | | [copy req to read buffer] |
339 | | | [add req to fc->processing] |
340 | | | <fuse_dev_read() |
341 | | | <sys_read() |
342 | | | |
343 | | | [perform unlink] |
344 | | | |
345 | | | >sys_write() |
346 | | | >fuse_dev_write() |
347 | | | [look up req in fc->processing] |
348 | | | [remove from fc->processing] |
349 | | | [copy write buffer to req] |
350 | | [woken up] | [wake up req->waitq] |
351 | | | <fuse_dev_write() |
352 | | | <sys_write() |
353 | | <request_wait_answer() | |
354 | | <request_send() | |
355 | | [add request to | |
356 | | fc->unused_list] | |
357 | | <fuse_unlink() | |
358 | | <sys_unlink() | |
359 | |
360 | There are a couple of ways in which to deadlock a FUSE filesystem. |
361 | Since we are talking about unprivileged userspace programs, |
362 | something must be done about these. |
363 | |
364 | Scenario 1 - Simple deadlock |
365 | ----------------------------- |
366 | |
367 | | "rm /mnt/fuse/file" | FUSE filesystem daemon |
368 | | | |
369 | | >sys_unlink("/mnt/fuse/file") | |
370 | | [acquire inode semaphore | |
371 | | for "file"] | |
372 | | >fuse_unlink() | |
373 | | [sleep on req->waitq] | |
374 | | | <sys_read() |
375 | | | >sys_unlink("/mnt/fuse/file") |
376 | | | [acquire inode semaphore |
377 | | | for "file"] |
378 | | | *DEADLOCK* |
379 | |
380 | The solution for this is to allow the filesystem to be aborted. |
381 | |
382 | Scenario 2 - Tricky deadlock |
383 | ---------------------------- |
384 | |
385 | This one needs a carefully crafted filesystem. It's a variation on |
386 | the above, only the call back to the filesystem is not explicit, |
387 | but is caused by a pagefault. |
388 | |
389 | | Kamikaze filesystem thread 1 | Kamikaze filesystem thread 2 |
390 | | | |
391 | | [fd = open("/mnt/fuse/file")] | [request served normally] |
392 | | [mmap fd to 'addr'] | |
393 | | [close fd] | [FLUSH triggers 'magic' flag] |
394 | | [read a byte from addr] | |
395 | | >do_page_fault() | |
396 | | [find or create page] | |
397 | | [lock page] | |
398 | | >fuse_readpage() | |
399 | | [queue READ request] | |
400 | | [sleep on req->waitq] | |
401 | | | [read request to buffer] |
402 | | | [create reply header before addr] |
403 | | | >sys_write(addr - headerlength) |
404 | | | >fuse_dev_write() |
405 | | | [look up req in fc->processing] |
406 | | | [remove from fc->processing] |
407 | | | [copy write buffer to req] |
408 | | | >do_page_fault() |
409 | | | [find or create page] |
410 | | | [lock page] |
411 | | | * DEADLOCK * |
412 | |
413 | Solution is basically the same as above. |
414 | |
415 | An additional problem is that while the write buffer is being copied |
416 | to the request, the request must not be interrupted/aborted. This is |
417 | because the destination address of the copy may not be valid after the |
418 | request has returned. |
419 | |
420 | This is solved with doing the copy atomically, and allowing abort |
421 | while the page(s) belonging to the write buffer are faulted with |
422 | get_user_pages(). The 'req->locked' flag indicates when the copy is |
423 | taking place, and abort is delayed until this flag is unset. |
424 |
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