Date: Mon, 17 Dec 2007 16:41:32 +0000 (UTC) From: Csaba Henk <csaba-ml@creo.hu> To: freebsd-hackers@freebsd.org Subject: Re: Disk sync at shutdown and fusefs filesystems Message-ID: <slrnfmd9lc.i6j.csaba-ml@beastie.creo.hu> References: <20071211001828.54e1da6b@deimos.mars.bsd> <slrnflug57.i6j.csaba-ml@beastie.creo.hu> <20071212134316.3d65f102@deimos.mars.bsd> <slrnfmbjph.i6j.csaba-ml@beastie.creo.hu> <20071216232655.5d829d41@deimos.mars.bsd>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2007-12-17, Alejandro Pulver <alepulver@FreeBSD.org> wrote: ><quote> > - Some "got hung in unmount" issues are to be sorted out (these > appeared on Linux, and they might or might not appear on FreeBSD). ></quote> > > IIRC you are saying that any user could make umount hang. And you said > this is an unintended behavior caused by the implementation, which > appeared on Linux and we don't know if it will happen on FreeBSD. > > Otherwise the daemon would synchronize the fs and let umount return > normally, and this wouldn't happen, right? > > If this always happens then what is the difference between happening on > a root/non-root mount, as it will hang anyways? > > If I missed the point again please correct me, and clarify the following: > Does the hang (point 2)/umount stuck (point 3) issues consist of the > same (I assumed so)? If not, please point out the differences. Oh sorry, I see my wording was still not clear enough... Point 3) and point 2) are completely different issues. Point 2) is about a _bug_ which might make unmount hang (contrary to our intentions). Point 3) is about the access control _policy_ of the "mounting with sync unmount" feature which is DOS capable: it enables some malicious code to make the shutdown sequence hung. [Btw, I used/use the "hang", "block", "make stuck" expressions interchangeably, I'm sorry if it's not correct English or just sounds unnaturally in some cases.] The same statement with more details: Point 2) is about a defect of a naive, straightforward implementation of handling the DESTROY message in the FUSE library. That is, if the daemon is mounted with synch umount, under certain circumstances (if I understood correctly, this amounts to killing the daemon with a SIGTERM [ie., the FUSE session terminates due the sigterm and not because of doing an unmount(2) on the fs]) the umount code of the lib falls into an infinite loop. This is a bug which may or may not affect FreeBSD once DESTROY is implemented for it -- the umount code in the lib is platform specific, anyway. So this is just about a possible bug which really falls into the "we will see it when we get there" category. OTOH, by the essence of the synch umount, mounting an fs daemon w/ synch umount means that the daemon gets the control over the termination of the unmount syscall. So being able to mount w/ synch umount assumes some kind of trusted state -- it enables a malicious daemon to block its unmounting. It's not a real risk if the unmount is done manually -- when the person who unmounts the fs observes that the daemon is blocking the unmount, she can turn to either a forced unmount or killing the daemon. However, during the shutdown sequence, which is automated, noone will be there to forcedly terminate the FUSE session, and shutdown might get stuck this way. So we have to decide how to control the access to mounting with synch umount. This is point 3). Probably I just provide an implementation of it for the kernel module and add a "sync_umount" option to mount_fusefs(8) and let it be as is and we'll see how well it works out, and what to do about access control -wise. Csaba
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnfmd9lc.i6j.csaba-ml>