Disk sync at shutdown and fusefs filesystems

[Csaba Henk]

On 2007-12-17, Alejandro Pulver <alepulver at 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