> > > I'm not saying fuse is worthless. It is a nice toy for single-user > > > systems. But I do not think we should be merging "allow ordinary users > > > to mount their own fuse's" before issues above are fixed. > > > > I think multi user systems are not all that interesting. And I > > suspect very few of them want reliably working suspend/hibernate > > (which they wouldn't get due to other issues anyway), or have weird > > shutdown scripts which stop when they are unable to umount > > filesystems. > > Weird shutdown scripts? I believe all shutdown scripts have this issue > -- if you want to [cleanly] unmount your / filesystem, you need all > the opens for write closed, right...? Which self-deadlocked fused > holding files open will prevent. > > > For paranoid sysadmins, I suggest not enabling fuse for unprivileged > > users, which is pretty easy to do: just don't set /dev/fuse to be > > world read-writable (which is the default BTW). > > > > So your reasons just don't warrant a big effort involving VFS hacking, > > etc. Patches are of course welcome. > > Well, I believe code with obscure, but almost impossible to fix > problems should not be merged... That code _has_ been merged, something like 3 years ago, and is doing fine, thank you. The unprivileged mounts code, which we should be discussing, doesn't change anything about that, except to not require another suid-root utility. Many distributions enabling unprivileged mounting by default _now_, so it's not as if there's some great danger in doing this slightly differently. > Anyway, I believe it would be fair to mention kill -9 no longer > working and shutdown/hibernation/multiuser problems it implies in the > changelogs and probably sysctl documentation or how is this enabled. Sure. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
