Chris's Wiki :: blog/linux/FUSEOnNFSUnmounting Commentshttps://utcc.utoronto.ca/~cks/space/blog/linux/FUSEOnNFSUnmounting?atomcommentsDWiki2018-09-26T14:23:53ZRecent comments in Chris's Wiki :: blog/linux/FUSEOnNFSUnmounting.By Chris Siebenmann on /blog/linux/FUSEOnNFSUnmountingtag:CSpace:blog/linux/FUSEOnNFSUnmounting:207485e40e849f7902d22c133513a76c38b6750bChris Siebenmann<div class="wikitext"><p>I think sshfs is doing '<code>fusermount -u</code>' when its setup fails, hence
the message, but yes, an explicit one fails with exactly the same
error message. As far as fusermount's use of <code>setfsuid()</code> goes, it
looks like it only does it for some operations, which don't include
a crucial code path where it tries to chdir to the parent of the
mount during the unmount process.</p>
</div>2018-09-26T14:23:53ZBy Alan on /blog/linux/FUSEOnNFSUnmountingtag:CSpace:blog/linux/FUSEOnNFSUnmounting:657930a1ecc210a583313947931764ab8c8fdf37Alanhttps://twitter.com/sourcejedi<div class="wikitext"><p>lol. `fusermount` is absolutely doing setfsuid() dances. With code that seems horribly fragile to me. Maybe the dance goes wrong on the error path only.</p>
<p>You don't show `fusermount -u` as the user (i.e., does that not work either?).</p>
<blockquote><p>modern Linux kernels have decided that they will do a full lookup through the path you give them to unmount (I assume that they have good reasons for this). Since umount2() must be done as root, this path walking is done with root's permissions. On NFS mounts, UID 0 generally has no special privileges</p>
</blockquote>
<p>Well, hum. It has to identify the mount somehow. Naive string comparison doesn't work (because of overmounts, or the parent directory of the mountpoint can be renamed). So it's the simplest way.</p>
<p>It would be nice if `umount2()` could bypass netfs/fuse/etc revalidation and specific permissions though! I think the deentries on the path to mount points are all pinned in memory. Seems like it should be possible, it's just that it would be an extra special case to maintain.</p>
</div>2018-09-26T12:13:38ZBy Simon Tatham on /blog/linux/FUSEOnNFSUnmountingtag:CSpace:blog/linux/FUSEOnNFSUnmounting:a91cab0195d8e9c4aa032a9e3000aa8fa17e0012Simon Tathamhttps://www.chiark.greenend.org.uk/~sgtatham/<div class="wikitext"><p>I often wish there was a way to set things up so that unmounting a filesystem also automatically unmounted any other filesystems mounted in subdirectories of it. (Probably by setting a flag on the sub-mount, though I'm open to persuasion that some other API is better.)</p>
<p>My main reason is that I like to set up filesystem mounts under my home directory. If my home dir is a non-permanent mount (e.g. on NFS, or encrypted) then that has to be done by my login script, which means my logout script has to unmount them all again, and if it fails for any reason or somehow doesn't run at all, then my home dir gets into a stuck state.</p>
<p>Whereas if I could set flags on all those submounts that said 'oh, and just automatically go away if you're still here when my home dir needs unmounting', that would be much more robust. And surely it would also solve your problem here.</p>
</div>2018-09-26T10:36:58ZFrom 193.219.181.219 on /blog/linux/FUSEOnNFSUnmountingtag:CSpace:blog/linux/FUSEOnNFSUnmounting:e420e1f74cd8e56ffb9f337b870284e222887505From 193.219.181.219<div class="wikitext"><p>You can disable FUSE by adjusting the permissions of <code>/dev/fuse</code> via udev rules (indeed Debian used to limit it to the <code>fuse</code> group only).</p>
<p>I've heard that at least one of <code>fuse.blacklist=1</code>, <code>module_blacklist=fuse</code>, or <code>initcall_blacklist=fuse_init</code> are supposed to work even for built-in "modules" (all of them being interpreted by the kernel, not by userspace like <code>modprobe.blacklist=</code> is).</p>
</div>2018-09-26T04:46:58Z