Date: Mon, 17 Dec 2007 14:15:04 -0300 From: Alejandro Pulver <alepulver@FreeBSD.org> To: Csaba Henk <csaba@beastie.creo.hu> Cc: freebsd-hackers@FreeBSD.org Subject: Re: Disk sync at shutdown and fusefs filesystems Message-ID: <20071217141504.1f3d8932@deimos.mars.bsd> In-Reply-To: <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> <slrnfmd9lc.i6j.csaba-ml@beastie.creo.hu>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/AFYVs7M_8nvkr5DdgWmpidl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 17 Dec 2007 17:41:16 +0100 Csaba Henk <csaba@beastie.creo.hu> wrote: > [This message has also been posted to gmane.os.freebsd.devel.hackers.] > 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 followin= g: > > Does the hang (point 2)/umount stuck (point 3) issues consist of the > > same (I assumed so)? If not, please point out the differences. >=20 > Oh sorry, I see my wording was still not clear enough... >=20 > Point 3) and point 2) are completely different issues. >=20 > 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. >=20 I understand now (about 3). So a user could write a FUSE daemon which never replies properly (or doesn't reply at all) to the DESTROY code, and the kernel module would be waiting indefinitely. Stalling the shutdown sequence. Maybe this could be solved with a timeout (see below). > [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.] >=20 I'm not a native English speaker, so these all seemed the same to me. Thanks for the clarifications. >=20 > The same statement with more details: >=20 > 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=20 > the "we will see it when we get there" category. >=20 O.K. > 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. >=20 > So we have to decide how to control the access to mounting with synch > umount. This is point 3). >=20 I can see 2 approaches to solving this (not sure if both are possible though): Maybe adding a timeout to the FUSE kernel module? I've seen the syncer daemon say "giving up on ..." when I had ATA errors related to configuration/cable problems (it retried for a while, and as disk couldn't sync, it terminated anyways). So maybe something similar could be implemented. Otherwise IMHO only root should be allowed to do such mounts, or having a sysctl disabled by default to allow users do this (like vfs.usermount). >=20 > 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. >=20 > Csaba When the implementation is ready, and if these problems are sorted out, do you think it could be enabled by default (at least for root)? Because that's the behavior most filesystems would prefer I think. Best Regards, Ale --Sig_/AFYVs7M_8nvkr5DdgWmpidl Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHZq6YiV05EpRcP2ERAuFGAKDgn5uOzqDqc81vzBU1SLIMHQrfHACdG7ZY XsA46Qb+XuxQIqnW+vwi/fY= =D6Ce -----END PGP SIGNATURE----- --Sig_/AFYVs7M_8nvkr5DdgWmpidl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071217141504.1f3d8932>