Disk sync at shutdown and fusefs filesystems

[Alejandro Pulver]

On Mon, 17 Dec 2007 17:41:16 +0100
Csaba Henk <csaba at beastie.creo.hu> wrote:

> [This message has also been posted to gmane.os.freebsd.devel.hackers.]
> 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.
> 

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.]
> 

I'm not a native English speaker, so these all seemed the same to me.

Thanks for the clarifications.

> 
> 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.
> 

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.
> 
> So we have to decide how to control the access to mounting with synch
> umount. This is point 3).
> 

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).

> 
> 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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20071217/507e4644/signature.pgp